Art by Sage Kellyn

NFT Rewards Strategy with jango​

We've been in touch with Code4rena this past week to schedule the review for NFT Rewards contracts.

Since our next governance cycles will only be able to put out funds in two and a half weeks, Nicholas launched a Juicebox project, NFT Rewards Audit Fund to help crowdfunding so that maybe we can get the review started earlier.

• Jango has been fronting funds for the previous two Code4rena audit contests, it's not sustainable to do it in this way. This project could be an interesting alternative;
• This will be the first experiment that we do with the Code4rena audit contest, hopefully we will have some model to share with them and they can use it for other projects as well;
• If we can put the funds down, theoretically we could start the audit contest on Oct. 7th, at the end of this week, although it's not very easy to get some steam up and running for this project in a short period of time.

But there might be another approach to handle this Code4rena audit contest a bit later:

• A lot of devs who tend to participate in this audit contest are going to be at Devcon Bogotá this next week and a half, and probably on their computer less often than normal, or at least less focused on problem solving;
• Given that contest will cost us about $70k, and the governance process takes about the same interval of time as Devcon, it seems a decent option to spend this period of time to tighten up some things and keep running more tests before the audit contest;
• We should be aware of the fact that there are quite a few moving peices right now. So it seems smart to take the next week and a half to make sure everything is in place, so that when we put out the NFT Rewards contract, it has been looked at by as many devs as possible;
• Once NFT Rewards contracts are out, we'll be working with a new piece of infrastructure which at its core is very crafty in its potential and has pretty compelling customization features, we might want to start to put weight on this one step at a time.

If we take the more prudent approach, we're probably aiming for the Code4rena audit contest starting mid of Oct, and a pretty fixed launch date for contract deployment synchronized with the frontend deploy since there're some Subgraph dependencies. It will be a matter of plugging in the contract addresses and shipping it for the frontend experience also, around Nov. 1st.

No decisions have been made on these time frames yet, but Jango is leaning towards taking the more patient approach. We've been sprinting a lot in the past month and frontend has been doing a lot of stuff with subgraph and frontend versioing. Maybe we should take it easy this month in a sense that everyone feels very good and all the moving pieces are very much in place. We will have all loose ends tied and ready to go by the time we launch.

The NFT Rewards contracts are chunky, which is a design choice in contrast to having many smaller contracts that each has scoped feature specifications. These contracts have serveral flags that project owners can turn on and off on deploy, so it's a little chunkier at the convenience of project owners. Over time if there's a demand for any particular version of these considerations, folks can add similar NFT-Rewards-style contracts to get ride of unused flags they may not want. But at first, similar to Juicebox protocol, we are going to deploy this highly customizable and feature-rich NFT Rewards contracts.

The versioning work in frontend seems to follow along and might be available soon. In that case, we'll do the frontend V3 deploy and flip the project creation to use V3 contracts. We will give the V3 project creation some time on its own before introducing the NFT Rewards as part of the creation flow. So if we take the prudent approach on audit contest, it will allow frontend to deal with any bugs or anything that happens in this period of time, since the NFT Rewards contracts will probably be around end of this month anyways.

NFT Reward Audit Fund by Nicholas and Jango​

The NFT Rewards Audit Fund is a Juicebox project that Nicholas created to help funding a Code4rena audit contest for the NFT Rewards contracts. Folks can decide to contribute to it so as to speed things up, even before the DAO decides to support.

Also Nicholas submitted a proposal for JuiceboxDAO to support and fund this audit contest. Once approved, funds will be distributed into the treasury of the Audit Fund project, to be paid to Code4rena later on.

If JuiceboxDAO does decide to fully support the expense of this Code4rena audit, folks who donated to this project before could possibly get their full refund through redemption. This proposal will serve on both edges:

• paying for NFT Rewards audit contest;
• pushing forward the partnership petential will Code4rena;

But even if this propoal gets approved, the earliest that the funds can be distributed will be the start of JuiceboxDAO Funding Cycle #33, around Oct. 22nd.

jango thought that it would be more ideal for the audit contest to start on Oct. 17th, but to achieve this goal, we might need to:

• encourage folks to contribute more funds into the treasury of the Audit Fund project when the proposal has not yet been approved;
• talk to Code4rena about the precedant that JuiceboxDAO has set funding the previous audit contests, and see if they're comfortable with having the funding proposal in motion and approved, or on pace to be aprroved by the time the contest starts, while the funds will only be available by the time the contest ends.

For context, recently Code4rena is interested in creating some Juicebox projects for any smart contracts or protocols so that anybody can crowdfund and start the audits for them. Hopefully, this Audit Fund project and proposal can help to push forward the JuiceboxDAO X Code4rena integration partnership by discovering a typical JuiceboxDAO dogfooding solution first.

Dr.Gorilla is working on an allocator which would allow projects including this NFT Rewards Audit Fund project to pay out funds in DAI, for the sake of convenience so that projects don't need to distribute ETH to multisig or any other address and then swap on exchanges for DAI. Instead, this allocator will take in the ETH from the treasury, check a few exchanges for the best price, and then swap the ETH into DAI before sending to the beneficiaries.

Concerning the question whether or not early donors of the Audit Fund project can get their 100% refund, Jango thought that it will be very probable, as long as JuiceboxDAO fill ETH in the Audit Fund treasury without minting tokens for itself and the redemption rate is set at 100%, as well as that the Juicebox fees are compensated by JBDAO. Jango also express his interest in seeing if the DAO is willing to put some JBX behind it as well, so that folks contributing and taking on the marginal risk can have a little bit of upside in so doing. Also from a membership perspective, it's another initiative to spread the JBX around from the treasury.

Broader JBX Strategy by Jango​

In the past couple months, we've been trying to figure out how to create a system where we can spin up a subsequent version of the contracts, accommodate them in the frontend, feel good about them in the documentation throughout all the contract interactions, which gives us some advantage later on if we were to encounter a situation where we need to move quickly to offer projects a way out of the current version.

But this is a temporary measure, eventually we want to converge our processes on our funds on the V3 treasury. Once everything is in place and we feel good about it, we want to create processes for folks that are currently upgrading from V1 to V2 to go over to V3 and make use of the tools there, and then we can start to build extensions further for projects on V3.

Eventually the JBX token should find some redemption value again on V3, for the time being the funds are somewhat scattered across the multisig and all these versions, although to some extent they'll always be since we might still collect fees on V1 and V2. But the goal, from the perspective of JBX, is to converge on the V3 treasury and allow the frontend to make some cleanup choices that we can re-focus on V3 going forward and be creative there without burdening ourselves with compatibility for V1 and V2 forever. It would take us back to the place where we were maybe 4 or 5 months ago when JBX was more frequently redeemed in the treasury, which is a really cool prove of concept of how all this works in principle and will tend to work in the future. Also it will be where the VE tokens can have their floor value against the treasury. Then the decisions we make spending on treasury directly affect the redemption value of JBX.

As a result, we can then move forward with some of the prototypes that we've been following along with. Extensions such as the JBX fee module would then reference the best price of JBX when someone contributes to the JuiceboxDAO treasury either through fees or whatnot, it would look to the market and swap there if the price is better than issuance, other it will add to our treasury and mint new JBX as it currently does.

That's part of the longer term JBX strategy. Jango hoped that we can find some stability again by the end of this year across all this expansion across versions, and then can start to reduce again and converge on V3 in this dirty JBX mechanism.

Defifa project by Jango​

A few governance cycles ago, we got some support to start building this really sick game that is gonna accompany the World Cup that's kicking off on Nov. 20th, and leveraging the NFT Rewards contract and scoping it down to a very narrow specific use case.

Essentially this game is a Juicebox project that's divided into 4 funding cycles enumerated as phases for the game's sake.

Phase I: Mint​

There's going to be 32 NFTs which are each different tiers in the NFT tiered reward contract. In the two weeks leading up to the tournament, anyone can mint any team for the same price (currently saying 0.022 ETH). As the mints increase, so does the game's treasury. The NFTs are in turn a claim on the treasury. During these first 2 weeks, you can burn your NFT to get your funds back, with 1:1 redemption.

So you can basically mint at will and then along the way if you no longer like the token distribution, let's say you minted England and then a ton of people also did, you can burn your England NFT and get your funds back.

At the end of the day, we're playing the game by taking the competitions outcome and trying to reflect the results onto this game and then recalibrate what each NFT is backed by, given the IRL outcome.

Phase II: Start​

Once the games starts, the treasury is locked and minting ends. There's no more new NFTs, and you can't redeem or refund, the distribution of all tokens are set.

What happens in between the game is open-ended, we can bring whatever rules we want. We can say it's a winner-takes-all situation where the whole treasury will belong to the NFTs of the winner of the last game; or we can do something more interactive, let's say there's a preset amount of the treasury allocated to one specific stage game and the winner of the prediction ends up with those funds or at least has their NFTs backed by those funds.

We're probably going to lean towards doing it in a simpler way at first. Each game of the tournament will have a preset portion of the total treasury:

• 0.416% for each of the 48 group stage games.
• 2.5% for each of the 8 first knockout round games.
• 5% for each quarterfinal game.
• 10% for each semifinal game.
• 20% for the final game.

For example, if England beats the U.S., then whoever holds the England NFTs will get 0.416% of the treasury during that group stage game, so on and so forth.

Phase III: Trade Deadline​

There will be a trade deadline after the group stage, all the NFTs will be non-transferrable from the trade deadline till the game's end. We don't really know how the game will play out from a bribery perspective, and the bribery certainly is an interesting component that we're not trying to dissuade entirely. We just want to create a mechanism that reflects as much of an expected outcome as we can, which means folks can feel pretty confident that whatever happens in real life will be reported on-chain.

Phase IV: End​

Once the game ends, the game is self referee'd.

Someone will upload a scorecard that basically tells the contract how the treasury should be distributed, which is going to take into account every outcome that happened in between from the start to the end. Let's say like England only won that one game and nothing else, then 0.416% of the treasury is going to England NFTs as per the scorecard.

The scorecard can say anything, but then each NFT holders across all teams have to attest to the correct scorecard to ratify it. Each NFT vote is weighted against the total supply of their team, and each team will have collectively 1 vote to attest to the scorecard.

Once the quorum is reached, the treasury is unlocked and anyone at that point can burn their NFT to reclaim ETH from the treasury according to the value determined by the scorecard. No funds will be distributed, just every NFT is now backed by the funds in the treasury in accordance with the team's result and also spreaded across the distribution of all token holders.

The coolest thing is that, you can fork this to run your own version of this whole thing, you can basically repeat this experiment for any tournament or anything you want, where you just basically mint a distribution to fund the game and have the same pieces that you minted also as a function of the outcome.

Roadmap of this Defifa game:

• We're going to start with the quick website by the end of the week, which just has this header and the rule section;
• We'll ship it on defifa.net;
• We'll add the mint section hopefully by next week;
• We'll kick off the game two weeks before World Cup openning games, which will be Nov. 05;

The only new contractual component is the attestation scorecard piece, which we've come to terms with the parameters and how it's built, so all is good.

The art is phenomenal, shoutout to Mieos for tuning together each of these teams, all of them have a little aesthetic feel, which is very delicious.

Juice accounting by filipv​

Filipv did a demonstration of Juice accounting app, which he made originally for JuiceboxDAO but ended up making it generic for all Juicebox projects.

If you want to get accounting for a certain project on Juicebox, you can input the required parameters and get some information for this project in return, which can be pretty useful for some project creators looking to deal with taxes etc. in a given jurisdiction.

Let's say we want to get accounting for TilesDAO, we put in the project ID, the protocol version and put in the fiat currency that we're using, it will touch things and write to the folders. For example, if we open up payments folder, it gives us the time stamp, ETH amounts, fiat conversion at the time of payment, and the caller.

You can download here and try to run the app if you want.

And also another app to calulate fees in the Juicebox protocol, which is only meant for JuiceboxDAO at this moment.

Juicetool nance update by jigglyjams​

If you go to the Juicetool Nance page, it will load the proposals that are currently tagged. （Here it shows # TBD, becuase we don't give the proposals any proposal ID until it passes the temperature check. ）

By clicking the New Proposal, you can have this proposal template: This template allows you to select a payout that goes to an address or a project, and specify the amount and number of cycles. And also it will resolve ENS name in the Receiver address.

Once you finish filling the fields and hit Submit, we get a proposal created. When you submit a new proposal, we'll still push it to Notion at this point.

Longer term roadmap for Nance:

• migrating JuiceboxDAO off of Notion to Dolt (a SQL database).
• figuring out the way to host on IPFS.
• getting version controls for our governance batabase.

Says who？ with Felixander​

And the correct answer is ... Sage.

MCSA update by 0xSTVG​

MCSA(Marin County Swim Association) is a nonprofit providing opportunities for people who can't afford to be in some high level tournaments, camps or clinics. On Oct. 16, 2022, MCSA will be hosting a Shooting Academy with Gold Medalist/NCAA Champion Jamie Neushul and 2020 Olympian/NCAA Champion Hannes Daube. This event will only charge $45 per person and MCSA will cover the balance of around $2,000 total.

OxSTVG would like to thank all the people who have donated and support the MCSA Juiceobx project and want them to know that the funds are being used in a positive way. A lot of people who would not have exposure to this type of high-level talent coaching can get their oppoutuity through the help of MCSA.

Bonus: Juicy Treasure with Nicholas​

Nicholas set up a Juicebox project called Juicy Treasure and put the project ownership NFT on auction on Zora, as a nice little experiment to get more people thinking about the different mechanisms of Juicebox.

Art by Sage Kellyn

Tech update with jango​

V3 Contracts Update​

jango: A week ago, we deployed the V3 contracts. We need to set up the juiceboxDAO funding cycles on V3, which will be a transaction that all the multi-signers have to sign for, and we have to synchronize it with the V2 and V1 funding cycles. So we're going to queue up this transaction to kick off V3 funding cycles this Saturday, run a quick 7-day funding cycle and then reconfigure it to align with the 14-day cycles of V2 and V1.

The V3 cycle won't have any payouts from it, nor have any redemptions. It'll basically just be a place for fees to come into from projects operating there. All is looking good.

And then we toss the ball back over to frontend to help with the user journey of versioning, and there's some subgraph related work that peri's working on. Maybe Aeolian can give a few updates on how versioning is going on your end.

Aeolian: Yeah, the codebase is ready for V3, or at least it's being reviewed without something to get merged yet. And peri's working on adding V3 support to the subgraph. Once that's done, we'll merge those two together and then we've got V3 on the frontend. Getting that out of the door, we'll then go full steam ahead on the upgrade path.

jango: Cool! Once the basic stuff is done, we should be able to start launching projects on V3, and then, as Aeolian said, move onto the upgrade paths for v2 projects and V1 projects to move over to V3, which is a pretty big deal. It feels good to finally have this end state of V3 that feels very stable. We've gone through iterations in production the past 3 months or so on V2, and we're looking forward to helping projects make the move over to V3 and helping V3 projects launch.

I spent the last week re-calibrating the NFT Rewards contracts, which were done prior to this versioning PR and just needs a slight API change to how the datasources are being called.

I've been also working on the Defifa game leveraging NFT Rewards contracts, which have been really useful to stress test some concepts that we are incorporating into the base contracts. NFT Rewards redemption is not a feature currently available in rinkeby.juicebox.money, but the NFT Rewards can be used as a redemption token, so that you can mint them and then redeem them to get overflow back, as opposed to your project tokens. We'll just add a few more properties in there to make sure that the tracking of token IDs and burn count of tokens etc. is going through cleanly, which enables the first phase of the Defifa game.

And it's always been useful building on top of the contracts at the time you're rolling them out or you're crossing the finish line, to make sure APIs are tight and some concept steps are extensible enough. But in any case, the NFT rewards contracts will be easier to iterate on than the core protocol, since they're just attached to any funding cycles.

To even prevent the need for that iteration, we're also trying to stand up a Code4rena audit contest for the NFT rewards contracts. There's a pretty cool plan with regards to this in the works stewarded by Nicholas. Maybe nicholas wants to give an update or some insight on what we're thinking there.

Code4rena Audit Contest Game Plan​

nicholas: So a couple weeks ago some people from C4A got in touch and suggested that they were interested in creating a Juicebox project for each protocol potentially out there on Ethereum, or at least ones that have created pages with C4A, so that anybody could drop funds into another project dedicated to doing C4A audit contests for other people, because they've observed that DAOs and companies often pay for auditing other software that they depend upon for their contracts or services.

We also feel that maybe individuals would be interested in doing that, too.

It's a little bit slow going trying to figure out how to do that integration with them, so we're thinking of just dangling the carrot by doing it ourselves first. Jango came up with a cool idea to just create a Juicebox project that anybody can contribute to and that will be dedicated to an audit of the NFT Rewards contracts with Code4rena. In the future, we will create a proposal to help fund that. If the DAO decides to support and is willing to pay for the whole amount of the audit, which would be the distribution limit for that project, everybody could potentially be refunded their initial contribution.

This is a little experiment of us and hopefully it'll get C4A to start thinking in terms of how they can receive funds from Juicebox projects.

jango: That's pretty cool if you take into account open source codes that no one is technically responsible for. Although I guess in the sense of Juicebox the JuiceboxDAO has somewhat claimed stewardship over the repo, there are many projects could be more open-ended. So creating a treasury where anyone from the public or anyone who's depending on that piece of infrastructure can contribute to, will help fund the wardens to look over a code, which would be pretty cool. Obviously if an organization wants to sponsor it instead, as Nicholas has said, then the original donors can just redeem their tokens for the proportional overflow which might be the full amount they paid.

nicholas: It's cool, and the partnership potential is actually really exciting because it's basically a win for everybody:

• New projects could be created if C4A goes forward with this.
• Code4rena would have all this money essentially captive for their contest audits.

I think this integration has a good chance of happening, even though it's a little bit complicated to imagine getting it rolling at scale permissionlessly for potentially any contract. I'm excited to try it with this audit.

jango: I feel pretty comfortable rolling the NFT Rewards contracts without the audit contest, but since we've already been on this tightening game for so long, it feels worth the extra week to move it past the finish line, and have it looked over by third party wardens as well. So If you see a project in the next couple days that's devoted to funding the audit contest, I may throw in there and others are welcome too. That way, when JuiceboxDAO does come in later, we don't have to do this whole retroactive compensation stuff that we've been doing in the past governance cycles. Let's get this thing through the finish line, we are very close.

Visibility update with brileigh and matthewbrooks​

brileigh: New release of Juicenews is out.

We also released a new Juicecast episode today with JuiceboxDAO contributor 0xSTVG, to talk about the Marin County Swim Association, a Non-profit project he created on Juicebox.

And a config article for Lexicon Devils, with another one for FORMING project that Lexicon Devils created incoming later this week.

matthewbrooks: We're making a multi-part deep dive podcast on ConstitutionDAO, so if any of you are able to connect us with people who were closely involved with constitutionDAO or important to that project, that would be awesome.

0xSTVG: It would be interesting to get the perspective of the Chinese Community when it comes to ConstitutionDAO. Maybe somebody can help connect some of those influencers from that side, because I know that was a huge push in the DAO and the Discord when that happened.

matthewbrooks: Absolutely. We're looking to have a very robust overview of ConstitutionDAO, from a lot of different perspectives. It's not going to be one narrative, but we will be pooling together a lot of different folks who will be speaking to all the events that unfolded. We would be super down to talk to folks from that side of things as well.

Update on JB high and new article with Felixander​

Felixander: Regarding JB High, I think it will actually be live this week, though still in its very nascent stage. Huge thanks to the Peel team particularly Blaz who has taken the lead on that.

The idea is to create something where project creators can jump in and immediately get a really quick and good understanding for how to launch a project, as well as the different tooling options available in this space. We're going to make the JB high into a educational hub and put in a lot of this leveraging content that we've made.

Regarding the article, I am also working on a config style article that's going to start with ComicsDAO, next probably with SharkDAO. And that's really also going to take a little bit of a signal for what JB high is trying to do and almost be like a Frequently Asked Question for how to deal with projects from a different project's perspective every time. So for ComicsDAO, why did they set their particular configs? when did they change that discount rate? why did they do it? I'll probably publish this article in a form of interview with questions and answers, so that it will be easy for project creators to quickly get the information they want.

Two truths and a lie with Felixander​

The correct answer this time is ... kenbot of StudioDao

Art by Sage Kellyn

Capsules project with peri​

The Capsules is peri's latest project of on-chain typeface that he launched just one day before this town hall.

This project of on-chain typeface introduces a standard to make it easy to store fonts on-chain. There're a lot of projects that use text in on-chain rendered SVGs these days, but if they want to use a custom font in an on-chain rendered SVG, they need to find a way to store that font on-chain. Also storing fonts on-chain is expensive and complicated, and there isn't a standard way to do it. For this reason, Capsules project introduces a new typeface contract interface in order to standardize storing fonts and make it easier to access.

Together with the launch of this project, peri also put out some NFTs as a Proof of Concept experiment for fonts, by which he tried to educate users how to load fonts from a typeface using this contract and throw them into an SVG which in turn gets rendered on-chain. There're altogether 7,957 Capsules NFTs with each one of them having a unique color, while users can only mint each color once. Users can edit the text of the NFTs and it gets rendered in the Capsules typeface.

People can also download the typeface here for free if they want, together with its variable fonts, which is pretty cool.

The typeface contract allows you to define the typefaces even when you deploy a contract without storing all the data for them, which means anybody else can just come and store the data, provided it matches what you define in the first place.

For this project, there are 7 special pure color NFTs that goes to people who store the 7 fonts 100 to 700. Folks from around the Juicebox ecosystem got news of this launch and stored all of them in just couple of minutes, which is a very decentralized effort to get some new infrasturcture onto the blockchain.

Definitely follow peri on Twitter to get more first hand info and all his genius ideas!

Nicholas also managed to make a prototype using the Capsules typeface to render some active data of a Juicebox project.

And filipv downloaded the Capsules fonts and set his terminal font to them, which is super super cool.

Versioning update with jango​

Jango and his team launched the V3 contracts in the morning of this town hall.

In the past week, we had another Code4rena audit contest of mitigation review over the updated V3 contracts. After this contest, the team deployed all the contracts again except for the JBProjects and JBOperatorStotre, which means projects currently have their project NFTs will keep their project IDs and they can choose whether or not to deploy a V3 funding cycle and token that syncs to their V2 versions, while all new projects will be built on V3 contracts.

Dr.Gorilla and 0xBA5ED have done a lot of work for testing and solving some very complicated problems along the way.

V3 contracts are essentially a mitigation of a few bugs discovered in the previous Code4rena audit contest in V2 contracts. The most impactful one of these bugs was that project owners can set a start time of their funding cycle in a certain way to overflow the storage of that piece of data, essentially allowing them to create a funding cycle at arbitrary points of time and mess up the schedule of things. With the assumption that community relies on project owner to be honest, we try to create as many levers as possible to at least give project owners the ability to lock themselves into things, but this bug would in a sense allow some unforseen reconfigurations if for some reason project owner and the community were no longer aligned in interest.

It is just a fringe case, either it could have been patched with a new payment terminal controller, or contract crew could have made edit in the JBFundingCycleStore to fix it. But it makes a lot more sense that people about to build projects on Juicebox want to be building on the best version of contracts possible, so the team did the V3 contracts and made changes in the JBFundingCycleStore.

The next move is to extend what was previously a V1 to V2 token migration terminal to be more generalized, so that projects can deploy a new funding cycle and toke if needed and make the move across as they wish. But the V2 contract will keep working and all the stuff there is solid.

It's really nice to have a versioning pattern ahead of time when things are still pretty slow these days. Both contract and frontend teams were taking this opportunity to create decent standards for projects to use to implement major-version migration in the future if any problem arises.

nicholas: If people have their V2 projects right now, should they be worried about it sitting on V2?

jango: No. We've talked to all projects willing to communicate about it and make them aware that the audit contest has been wrapping up, and the broad base of projects has already had trust vectors established between project owners and the communities, so it should be fine.

nicholas: Is there a timeline for the feature of token swap?

jango: We current have this mental model that people paying ETH and they will receive project tokens, so projects might also use it to receive the old version of their project tokens and then issue a current version of token back out at a rate of 1:1. Under the hood, it looks like a payment terminal, and also in the frontend there's going to be a settings module to make the process easier for projects to do it.

Stay tuned for updates on all the work of the versioning stuff. The next thing for us will be to figure out how to deliver effectively. We have a lot of prototypes of this at the finish line, but given this V3 deployment, we want to make it work from V1 to V3, and from V2 to V3.

And there's some cool stuff we can do with extensions in V3. You can make pay delegates that receive part of the funds before they go into the treasury. This is a new feature that no one has used yet, and we're building the first one with the NFT Rewards, because we found that it would be really useful if some of the payment could be routed directly to a delegate. You can run arbitrary contracts that actually receive parts of the funds paid in, and the same with redemption, in which you can run delegates that receive part of the reclaimed funds automatically.

The GitHub repository of V3 contracts can be found here

Visibility updates with brileigh and matthewbrooks​

Juicenews newsletter​

The new release of Juicebox newsletter can be found here

Config articles​

The config articles are going to run through how a project is configured and some of reasons for those decisions made, to help new project creators understand why certain projects are using a different configurations and why they're making those decisions. So if new project creators want to build a similar project, they can look to that article as a reference point for their own project.

Brileigh and Matthew just launched their first config article here.

Juicecast (Juicebox Podcast)​

They recorded a new Juicecast episode with 0xSTVG about his project Marin Swim County Association, this episode will be released later this week.

They also made a video interview with David Phelps, the founder of JokeDAO, which they plan to upload to Juicebox Youtube channel later.

Work Plans​

• Another video interview with Robin from Defiant about creator economy.
• A retrospective deepdive on ConstitutionDAO.

They also have the plan of making a series of podcast featuring some famous/symbolic projects of Juicebox such as ConstitutionDAO or MoonDAO, coupled with some long articles that go through the history of them, as well as some config articles about how these projects were set up which will certainly be reference points for new project creators.

Interface with sunnndayyy​

Interface is a mobile APP that allows you to follow your friend's wallet, lays out all the information in the feed like a social Etherscan and lets you surf Web3 with a better UI.

Interface community has recently transitioned to a DAO, with a hybrid model between the Labs and the DAO. And they want to start doing some interviews and learning about progressive decentralization publicly. So they're looking to hold a series of Twitter Space on the challenges of decentralized coordination and stuff like that over the next few month.

They feel there will be no better community to talk to about these topics than Juicebox, so they want to invite the core contributors of JuiceboxDAO as their first guests to discuss on how to activate participation in governance in the early stage in a project's lifespan.

sunnndayyy also introduced that this APP is still in a closed beta version, so if people want to download it to try using it, they have to go to their website to sign up for early access.

G-Play updates with Sayid​

G-Play is a Juicebox project of P2E gaming platform where users can stake $Matics to play with each other on Polygon.

Recently they started their beta testing and onboarded their first users to the platform.

One of the new features they have, is a statistics page that shows how much the users have unclaimed $Matic they can withdraw.

Sayid and Mieos played a game to demostrate how the game goes on the town hall.

As now it seems a little troublesome to buy $Matic on exchanges and bridge it to the Polygon Mainnet, Sayid also announced a 500 $Matic scholarship so that users can use the built-in request function to ask for $Matic from them.

Two Truths And A Lie with Felixander​

The correct answer is ... Viraz.

Forming event Vol III with darbytrash​

Lexicon Devils are going to host a new Forming Vol. III event, FLOPPY x FORMING, on Sept. 24th 3pm PST, which will have 3 musical performaces and a FLOPPY walkthrough, at the Juicebox HQ in VOXELS.

The stage is set, welcome to join us then!

Art by Sage Kellyn

versioning with jango​

Contract crew has finished the versioning project, created the Juicebox contracts V3 repository and merged everying inside, before the repo was passed onto some wardens in Code4rena to implement a mitigation review for updates made with findings from last Code4rena audit contest.

Jango said the mitigation review will probably last for a week, and encouraged our community to stay tuned and help out with any questions or feedback that externat auditors might have.

A big work now will be working together with Peel to finalized what UX we should use to get new projects to use the V3 conract.

Projects that are currently operating under V2 will have the choice of deploying a V3 funding cycle and synchronizing, then deprecating their v2 version funding cycle. We will provide instructions for that process. But in this case, the communities of these projects will have to go through a token swap transaction, which isn't entirely ideal. If there are projects that don't want to go through this trouble, we'll deploy an ETH payment terminal and a JBController for them to migrate their current payment terminal and controller to.

For those who want to stay on V2, they're welcome to do so, it'll just be a little bit more follow-on work from contract crew.

Huge shoutout to Dr.Gorilla and 0xBA5ED for coming through and helping out in the last serveral weeks, and big shoutout to 0xBA5ED for a really intuitive solution to a little rounding error that we were dealing with last week.

juicebox.money Next Gen UI with Strath​

The frontend team found out that the biggest pain point for our users, which impacts Juicebox most and make it suffer from a very high dropoff rate, is the project creation flow. After some user testing and behavior analytics, our team finally went through the way to simplify this process and make it a more enjoyable experience to get people launch their project on Mainnet.

Strath was sharing his screen and showcasing the improved UI design

The biggest feedback they had was the step 2 of the 3 steps in the current creation flow, the Funding cycles which is some kind of tiered approach and has a lot to go through.

They are trying to break it down to simplify everything, get rid of the cognitive load and give people the ability to make one big decision per page.

Here's what the improved UI looks like:

And Strath was explaining the tabs in the new UI one by one.

Here is the Figma page if people want to leave their comments on this work.

This is not 100% complete and there're some small elements still being worked on. They will do some user testing, so there'll probably be iterations on it down the line.

There will also be some templates, so people can select the template and just go from there, instead of needing to jump into the creation flow.

Q: Do you have any plans or any prototype for allowing a user to launch terminals from there, like custom ERC-20 terminals?

Aeolian: It's quite an easy thing to create, but the main issue is what do we do on the project page, which still need to be conceptualized what it looks like for a project to have multiple terminals. That's probably the next big design project.

Jango: I even wonder if that's in the purview of juicebox.money to experiment with, because there're a lot of ways to go about this. It seems all this stuff is best to serve as an experiment with a juicebox.money fork or something that specifically tailored towards those use cases, and finding out how to fold that in nicely will be interesting.

It gets a little complicated, but it does provide particular accounting niceties if you really want those terminals. I think, from a protocol perspective we can make sense of these logically, but from a UX perspective it will take some work really figuring out what the priorities are.

Two truths and a lie with Felixander​

The correct answer is 0xBA5ED.

No.3 about the socks is a lie.

MTOTM AMA with epowell101 and Michaelmaher​

Background and concept​

Epowell101: This concept of MTOTM started with some lived experience and some conversations they had with some early DAOs and DAOs founders, in a sense that there's a need for additional diversification early on instead of waiting untils much later and needing an OTC desk to do the swaps or to negotiate for over months.

What if we, a bunch of DAOs at their very earliest stages, pitch in to a shared pool(Juicebox in this case) and get back a token that represents percentage of the meta DAO that we have just created. So you get some diversification and also some meta governance in which you get certain number of other DAOs who are care about how you're doing and potentially could be an independent voice in your Discord or in your governance to provide an independent perspective.

As we all know, there're a lot of launchpads out there and maybe lots of use cases, but we realized that we should focus on the primitive of DAOs pitching in and getting back while referring to an oracle to get the ratio. That's where we needed a name for this concept and we came up with MTOTM( \ˈemˈtō-təm\ ), which is supposed to stand for Many To One To Many Swap.

jango: To add a little context, we're leveraging these custom payment terminals to basically accept project tokens back into them and issue another project token outwardly, and that's kind of how it ties into the infrastructure that we're working on, the protocol developers are working on. It's cool that it's scoped into its own project and has its own application, but from the primitive perspective, as everyone was saying, it's nice to use these familiar pay functions in token issuance practices.

nicholas: If I'm getting part of the ideas, it's like token swaps between DAOs and also potentially collecting token for many different DAOs and generating one token that is the representation of all those different tokens in one index fund, which allow you to do interesting things and mutually incent each other. Is that the idea?

epowell101: Yeah, that's exactly it.

Explanation of mechanism​

michaelmaher shared a GIF file in the town hall channel:

michaelmaher: At the base of everything is the extensive use, if we all are using ERC-20 terminals to facilitate this process because what the DAOs pitching in will most likely be ERC-20 tokens, we'll have to navigate the use of these terminals to facilitake DAOs coming into an index, creating that index and spitting tokens back out to them.

With that, there's the ability to use different price feeds, using the Juicebox protocol. If a DAO's ERC-20 tokens coming in and they don't have a current price feed, probably because they are not traded on a DEX, we can set up custom price feeds as well.

But we also want to encompass it in the tradtional Juicebox project architecture, by using a regular project that can receive ETH and manipulate some different split data to send it out to other addresses.

Investors want to come in and spend their ETH to get an index token in the initial raise, and DAOs will also come in and get their DAO tokens in the swap. So all the swap needs to happen under the same umbrella, and that's really what MTOTM is about.

We also don't want to dilute the initial investors either. When they're coming in with ETH expecting some amount of tokens back, we want to make sure that's kept true till when the DAOs are coming in.

We're looking forward to developing some other terminals especially for this use. When you've got multiple projects coming in, you have to launch a terminal per project. Of course, that's not the most gas efficient thing, so we're also looking to help build some multi-token terminals , where you have one terminal and a bunch of tokens can come into it and help facilitate the whole process.

And the final part will be how to distribute everything. ETH will be distributed in a traditional way most Juicebox projects do and routed to the DAOs because it's a way of fundraising.

When you look at that GIF image, the whole point is to make it very simple for the users, and to have all the complexity under the hood.

Community support​

jango: Shoutout to you all for really figuring out how all these interfaces work and getting a sense that this can be pulled off with the network's treasuries that we've got going here.

I think there hasn't been full time attention from a lot of the folks that really know the protocol intimately well and have built it, you all really are carrying the load and understanding how things work and prototyping and asking really good questions very frequently, much appreciate it. Hopefully as we wrap up some of the work that we've already committed to, such as versioning, NFT Rewards and stuff over the next few months, we'll be able to be more hands-on and take this through the finish line to some MVP so that we can actually see this animation play out on a website.

michaelmaher: If anyone is interested in the project, you can check out our GitHub repo. And also welcome to join our Discord server and let us know what you think.

jango: There was a grant proposal to help sustain and fund those research this past round, which didn't meet the quorum in temperature check. A lot of this type of research work is more in the background and not really in everyone's face frequently, we are trying to figure out better ways to really highlight developers from around the ecosystem who have been working on it consistently.

I think this is one of the cases that we may not have a full thing ready to go in the near future. There's been a lot of understanding of how things work and prototyping how to really push the limits of how things might work, which is exciting to me. I would love to see it supported, and obviously the best way to support is just being around and helping to answer question and prototype and actually pull the thing off. It does take time and attention, we know that it's hard to prioritize things, but be on the lookout for grants of this nature going forward.

Further discussions​

nicholas: Let me run through this once more to make sure I got it clear. So the impetus is twofold:

1. to allow DAOs to swap tokens with one another, by making contributions of their own DAO's token to another DAO's Juicebox project and receiving that DAO's tokens in exchange
2. to enable the creation of an index fund and the fundraising for all of the DAOs that contributed their project tokens to this index fund so they can collect ETH.

Is that a good summary of the motivation?

epowell101: The DAOs and investors will all get back the same tokens that created by the meta DAO, but the DAOs will also get the ETH.

jango: I think the main thing from my perspective that is important to note is that right now we have an ETH payment terminal and a generic ERC-20 payment terminal. The ETH payment terminal is deployed and leveraged by juicebox.money. The other one is an ERC-20 payment terminal, let's say DAI, and that would work the same way.

You would issue a rate at which project tokens are issued out when one DAI comes in. If you run both an ETH terminal and a DAI terminal, you want to have the project token issuance rate be only correlated to one of these assets. Let's say 1 ETH comes in 1,000,000 tokens go out, and 1 ETH worth of DAI comes in 1,000,000 tokens go out. Now you can imagine a project token version of the ERC-20 terminal. One project's tokens get issued at some rate of the external project tokens coming in.

The interesting part is the price feeds. At what rate tokens get issued out when something comes in, and how does that relates to other terminals you are also using? That requires you to write price feeds and payment terminals. And then how do you write multiple payment terminals that can generalize this so that you don't have to deploy a new payment terminal for every project that wants to use this? You don't deploy a DAI terminal and then a SHARK, PEOPLE and JBX terminal each time. You can just have a generalized version of this, which is also an interesting problem here.

nicholas: So let's say you have a multi-token terminal that accepts SHARK, PEEL, CANU and WAGMI to create a Juicebox ecosystem index, it would not just have static rates for each of those versus the project's own token, but instead variable rates depending on the value of thos project tokens, right?

michaelmaher: Depending on the value of thos tokens, but some projects might be in their super early stage and we might negotiate a price to start, so maybe they all will have the same price. There're a lot of different ways in basically working with the prices contract set up in Juicebox.

nicholas: So the first step on the roadmap is this multi-token payment terminal to enable some of those ideas we talked about.

jango: I think the multi terminal is how you automate a lot of the operation overhead to set this up manually. I think the manual first step is to have one terminal per project token that's facilitating this, and to have prices feeds and everything plugged in, and the expectations are all set and things are well tested. And then the next step is to automate the operation overhead.

michaelmaher: Yes, we've been trying to develop the multi-token termianl and that's still in progress, so that's more of a future what this can be.

epowell101: We have stood up on testnet versions of this using the single token terminal, it's going to be very simple, because we just want to get to the MVP, but there's some UX work got starting as well.

Kmac: Isn't it an index built on token set?

michaelmaher: Okay, they kind of do this, but the reason that we're trying to be different from them is that they have these certain stipulations within a token set. One is that you have to be listed on a DEX platform or have some type of liquidity, so you have to have a pretty well launched token. Early stage projects are not going to pass that set protocol if they want to join. Also there is no real governance built in with that, you get this kind of index token per se, but the governance of that doesn't really work well. So to us, this is a different niche product that can facilitate a lot more projects out there.

jango: Lastly, just to emphasize is that this is an experiment, and there's a lot of unknowns, a lot of open questions. So let's ask those and let's hypothesize and talk about them. Who knows if it has longevity, but I think it's worth. I think there's definitely applications of this or derivatives of this concept that can be quite powerful.

Art by Sage Kellyn

Versioning with @jango​

This versioning project is a prerequisite for almost all the other protocol things, and mostly everything of it is complete now.

After the Code4rena auditing contest, there're a few changes need to be made to the protocol to ensure the protocol's risk aversion and longevity. Jango is leading the work now instead of waiting and patching problems that might rise later. A lot of the changes don't really affect the V2 features set, and everything is pretty much finalized at this moment.

The next step is to run another Code4rena contest on the updated repo. Jango is trying to get a mitigation review for the past Code4rena audit, which is to check the changes to the codes from the results of that audit, hopefully by same group of wardens from Code4rena.

The Juicebox projects contract won't be changed. This version won't be a requirement for all existing projects, which mostly won't ever run into some of the inefficiencies discovered. But new projects going to be build will use this new version.

Frontend has deployed a new settings page, a revamped and powerful settings page for Juicebox projects in the juicebox.money site last week, we'll leverage that to give project owners some confidence over how they're managing their treasuries across versions.

In our chats, we're calling this contracts update V3 but it shouldn't be taken as another major version as V2 was to V1.

@nicholas has been exploring, with as @trebien our main contact to Code4rena, a longer term cooperation with them, by which we can get preferable rates and more flexible contests.

Nicholas has put up a proposal for a larger budget for six months or a year for Code4rena contests, if passed, we can do many smaller contests as necessary for things like the NFT Rewards or small updates to the protocol.

The draft of this proposal can be found here, and the Discord discussion happens here.

NFT Rewards might also be rolled out at the same time, unless the community insists on having it go through Code4rena as well. The NFT Rewards is something that the devs can propose new ones at any time and projects can use updated version for their subsequent funding cycles.

Immunefi bug bounty​

@filipv wondered if we have a timeline for the Immunefi auditing and testing for the updated contracts. @jango thinks the Immunefi is less about auditing and testing, but more about bounties for hackers to choose to report vulnerabilities instead of exploiting them. He thinks what we offer most projects to build using Juicebox is the infrastructure as a service with the security model coming with it, but as the protocol grows and our day-to-day operations decreases, there might be a need to designate someone as an insurance mechanism.

@nicholas explained that the proposal we approved before to create a $100,000 Immunefi bounty has expired, for the reason of not implementing it within the contraints of that proposal which had a deadline. He also thinks we might consider change a service provider other than Immunefi, because they charge a 10% fee even though we are the one to custody the funds and triage the bug reports and payouts. He also suggested that the timing for a possible bug bounty should be after the mitigation review and deployment of the updated contracts to Mainnet, for we might need to make any bugs outstanding out of scope thereafter.

Devcon programming with @bruxa and ThirstyThirsty​

"Thirsty Thirsty is an ancestral remembrance project disguised as the coolest food and wine club on Earth. "

@bruxa is the founder of Thirsty Thirsty DAO, this community has been in existing since 2014 and set foot into Web3 in November 2021. They are a community of food and natural wine lovers, enthusiasts, experts and Earth stewards focusing on the cultural restoration and ancestral agricultural practices which they see as a really critical component to mitigate climate crisis.

Last week, @jango talked with @bruxa, @Zom_Bae and a few other folks about how we could partner with other communities who already have a leg up on creating events and bringing people together, and how we actually could partner from a funding perspective to do things like during the Devcon Bogota.

Oct. 10th, during the Devcon week (Oct.7-16) in Bogota, will be the indigeous people's day of the Thirsty Thirsty community, @jango and @bruxa are having the idea of creating an event that's Dev focused and bringing people together in an open-ended forum just similar to how JuiceboxDAO did on NFT NYC where people can come together and share ideas and be inspired by whatever happens. Also projects running on Juicebox or leveraging Juicebox can use this space to create a space for their own community to come together, while the JuiceboxDAO can partner with Thirsty Thirsty to provide food and dirnks to accompany this event.

Thirsty Thirsty NFT membership​

The Thirsty Thirsty is a 501(c)(3) entity that can accpet crypto donations.

Currently Thirsty Thirsty has their own membership NFT minting, with which on one hand they are trying to bring people together to experience the power of nature through food and wine in the cities and land, on the other to empower and share what this tooling is with their community some of which have been left out of financial sovereignty.

They're pretty interested in how Web3 tooling can help remedy a lot of issues with the labor chain and create equity in their communities all along.

They're also very excited to play with some smaller limited edition airdrops through Juicebox as a fundraising mechanism, especially tethered to some event that they're planning.

K.Group DAO with @Jermaine.A​

K.Group DAO is an affordable housing DAO, they have a unique solution to solving a housing shortage and trying to combat the affordable housing crisis in the U.S.

Solutions to housing for low-income​

The house below is an actual one in Houston, Texas, which was 4 bedroom house origially (left), and they converted it into a 12 bedroom one and added another bathroom. By this moment, there are 12 people staying there already.

You can also take a look at what the house is and its renovation by scrolling down to the bottom of their homepage and explore their first home.

What they are doing right now for this solution to house low-income individuals are:

• rents are between $650(small room) and $800(large room)
• all the rooms come fully furnished
• free internet, free laundry and all the utilities taken care of
• no first month's and last month's rent and no security deposit
• leases are on monthly basis so tenants can move if they wish

@Jermaine also said this housing model could be used for anything anywhere in the world, for the conversion that was done is just unversal.

Goals of the DAO​

The reason why they set up a DAO is that they think the DAO will be better to upsolve this housing issue with affordable housing.

When it comes to the project token $KDAO, they try to keep it as simple as possible, just strictly a governance token. Decisions to purchase any house or pull equities back into the project treasury will need to follow a governance procedure and be voted on with governance tokens.

They are an LLC entity licensed in Wyoming, so they can purchase physical assets and have bank accounts, etc.

The governance of this DAO will not only be about real estate, it might include the following according to @Jermaine:

• house purchasing
• renovaton
• marketing (local churches, community centers, online housing platforms)
• management
• maintenance

Eventually they want to create an online platform to where those rooms are listed and anyone can access them anywhere in the world.

Their ultimate goal is to house at least 10,000 migrant families within 2 years, and be the first DAO to sign a government contract as a contractor for Department of Homeland Security to help and house people.

Two truths and a lie with @Felixander​

The correct answer is @gulan

Defifa with @jango​

With the World Cup Qatar 2022 upcoming in November this year, and being one of the first global events after Covid, @jango thinks this could be a meme shilling point in some way. And he landed on a mechanism, a self-governed game system, facilitating the incoming NFT Rewards and the NFT voting system. (If you are interested in this project, you can read the Defifa specs here, and join the discussion in this Discord thread)

Essentially it'll be a bit hard to really wrap your head around it, unless you really know how the NFT Rewards system works and how it can be extended to support this. A surface perspective the community understands the NFT Rewards contract is just 3 NFT tiers that project owners can put up on the juicebox.money site, and the price thresholds that contributions need to cross so as to get the NFTs minted to contributors' wallets. That's very much the basic case of this contract.

But this contract can do a lot more.

A winner-takes-all scenario as an example​

Imagine like two weeks prior to the first day of World Cup, November 20th, someone deploys a treasury that doesn't have an owner. He can preprogram the rules upfront and the game will play itself out and end in a certain date. There is no funds in the treasury to start out, and there's zero tokens minted.

There will be 32 NFT tiers representing each of the teams in the competiton. It's a open mint, so anybody can mint any number of any of the tiers.

After two weeks when the first game starts out, minting will be closed. So everyone has their NFTs, which are all transferable and regular type of NFTs.

Let's say, we have 100 Brazil's NFTs minted and 10 Japan's minted, which will give you a sense of people's confidence of which team is going to win the competition. Now we have these outstanding NFT tokens and a loaded treasury which is the funds of the game.

At the end of the game, let's say Japan wins the competition, there'll be a self-governing process to submit a scorecard on the contract. Then all the NFT holders attest to the scorecard which they deem is correct, via a mechanism that will hopefully keep the result honest. Let's say someone submits the Japan scorecard and someone submits the Spain one, it'll be all the participants' responsibility to attest to the correct result.

Essentially all the scorecard at the end is a redistribution of the game's total funds. During the first two weeks open mint window, anyone can burn their token and get their funds back. The redemption rate is 100%, all NFTs are worth what was put in. But at the end of game, all the scorecards are the redistribution of this redemption rate. So basically a redemption delegate can be created to make all of the treasury now back the Japan NFTs instead of all other NFTs. The funds don't need to be distributed to the winners, instead they are reorganized to back the winning NFTs. Although now you can burn 1 Japan NFT to get 10% of treasury, but that'll be just the floor price of that NFT at the very least.

More complesx version for intra competition game​

You can also extend this mechanism to take into account intra competition matches.

Let's say if your team makes it out of the group matches, your NFT will be backed by 5% of the treasury，if you make it to the Top 3, it can be like 3rd place gets 15%, 2nd place gets 20% and 1st place 40% of the redemption.

All the scorecards at the end are basically the resulting redistribution of what back each NFT, then everyone holding the NFTs has on-chain vote from each tier to attest those results. And you should create the value of each vote so that people can't game the system in an obvious way. Let's say 51% of all NFTs minted are Spain, if you do 1 NFT 1 vote for attestations, Spain can just say it won and then vote itself in. So you have to spread out the weight of each tier's vote across the teams based on team's total supply, or something like that.

Actually this NFT Rewards contract that we built is a version of a governor contract that lets each tier have independent voting utilities, you can create votes that recognize a particular voting weight of tier, as opposed to just one NFT in the context of the whole system. All NFTs of all teams are in the same contract, but they often have different voting capacity for attestation, they can be backed by different redemption values given the end state of that scorecard.

Other thoughts​

You can also pre-allocate like 10% of the game's treasury to be shared by people who voted for or attested to the correct results, giving people an incentive to participate.

@jango thinks we should play it really simply here at first, and if it works out, it could be a cool thing that scales, you can have this play itself out in different athletic competitions and etc.

This is something that's been on his mind, and it's an extension of the NFT Rewards work that's slated to come out soon.

And there's for sure some cool game theory to tease out. Let's create something that encourages an honest attestation process. Everyone knows the real result and it's black and white, but will anyone defect? or is everyone incentivized to report correctly?

Sayid: Concerning the attestation, couldn't we bpass it by making some kind of API or using existing API to check the scores of the games?

jango: You could maybe pull in an oracle that's attesting to that result, but I don't think that's necessarily the goal here though. It will also be really interesting for the purposes of this being a generalizable Juicebox project that we can create a mechanism where the game theory works itself out, and the participants are encouraged to report correctly. That way, anyone can deploy a treasury in a game and it can load itself up and then be resovled all in a self-contained format.

I think this is also maybe an invitation to brainstorm other World Cup related shindigs that people want to stand up. I think this is maybe something worth doubling down on, and also we can get other Web3 projects in on it. I don't think this is a Juicebox specific thing that we do and try to get an edge on other protocol. This is a pretty cool coming-together celebration of the world through sport.

Art by Sage Kellyn

Business dev with @0xSTVG​

0xSTVG has been actively reaching out to some blockchain and web3 clubs at universities. The responses were quite warm, and they have been setting up talks with Juicebox, as well as having some in-person presentations and possible hackathons.

He plans to submit some proposals in the upcoming months, trying to help onboarding students and web3 enthusiasts in colleges and universities. He is gearing some of his efforts towards recruiting those types of builders.

Gplay studios with @Sayid​

@Sayid came to the Town Hall 3 weeks ago, did a demo with some preliminary designs of his platform. He founded this P2E(Play To Earn) arcade platform called Gplay Studios where uses can make profit by staking $Matic and wagering against each other in classical games on Polygon.

Except for the Tic-Tac-Toe he showed last time, recently he has added another 9 games to the platform.

New features developed:

• Game invitation link, which can automatically connect the person to a game someone else created,
• Rematch function, which player can use to request a reset of game and changing the opponent

The Discord server of Gplay is here, anyone who is interested in his project can join and have fun over there. @Sayid also said he would be hosting some gaming nights once all the bugs were fixed.

Nance Funding cycle configuration demo with @jigglyjams​

@jigglyjams did a demo on how he runs the Nance script to query from a Notion database of payouts and use those data to submit a Gnosis transaction to reconfigure the parameters of a new funding cycle.

His next step is to query payout addresses and payout amounts from proposals that have been approved and get them merged into those databases for reconfiguration of funding cycles.

Also he is going to work with @twodam to set up a frontend to configure Nance the Gov Bot in a Juicetool page. But he's also a bit concerned about where to store all the configs of Nance at this stage.

Banny drawing contest on JokeDAO with @nicholas​

@nicholas was hosting a Banny drawing contest using the JokeDAO voting machenism, in order to help showcasing the JokeDAO V2 new feature of uploading images as contest submissions. Everyone could submit a Banny/Bannyverse drawing in a submission period for others to vote, and the voting would be open once the preset submission period was up.

@nicholas minted the voting tokens and distributed them by airdropping to whoever has taken part in the JuiceboxDAO governance voting on Snapshot before. People receiving this token can vote for whatever images they like, and the image that gets highest votes win the contest.

And @nicholas also made a tutorial about how to create JokeDAO contests for Juicebox projects, which can be found here.

The winner of this contest was @brileigh, and the image that got the highest votes is:

Another upcoming new feature that JokeDAO will be developing, which is also funded by JuiceboxDAO, is the executable contest, in which projects can signify winning conditions so that the winner can be executed on-chain after the contest.

@filipv suggested that JokeDAO can also set up some thresholds, such as top 3 or top 4 in the contests win. This can be useful in application scenarios such as different prizes to Top X winners, or Top X winners get to be qualified as a member of a multisig, etc.

And @seanmc also said that they're talking with IPFS about image uploads within the website, which will be an amazing integration to it if implemented.

PeelDAO updates with @Aeolian​

PeelDAO recently onboarded 2 very awesome designers, @Strath and @Lawrence, respectively working on the redesign of the project creation UX and an update to the homepage. Hopefully these two efforts will reduce our currently high bounce rate for the website.

And other big frontend projects underway are:

• NFT rewards, this is already on Rinkeby so people can play with it already.
• Settings page, which @Jmill is currently working on and hopefully will be ready by the end of this week.
• Versioning, a strategy to manage multiple versions on the frontend.

Some features that have been shipped:

• CSV imports for payouts;
• CSV exports for payouts and reserved tokens;
• Juice SDK, which is a toolkit that makes it easier for people to set up frontends on Juicebox protocol.

Also they have been finetuning a lot of dev performance security work, running through all the dependencies and upgrading them.

One thing they are planning to implement is the Twitter verification, currently people can put anyone's Twitter into their Juicebox projects.

Juicenews newsletter new release and Juicecast new episode by @matthewbrooks and @brileigh​

A new release of the Juicenews newletters on Aug. 30.

And a new episode of Juicecast featuring @seanmc of JokeDAO. And @matthewbrooks urged us to at the very least listen to the first 10mins, which should be very great!

Two truths and a lie with @Felixander​

The correct answer is @Gogo, and he's a great story teller, try to tune in to his story of being surrounded by "Shark DAO" in Australia at 35'37" of the Town Hall recording.

StudioDAO updates with @kenbot​

kenbot: How can the audience finances the movies they want to watch? How can we really put the audience in charge?

StudioDAO is defining in a different way what a DAO can be.

Problems in the traditional filmmaking industry​

The traditional financing for filmmaking is more or less like this:

1. you go and sell the movie to investors,
2. investors take the equity, the rights to distribute the film,
3. investors make 120% on their money and get 50% of everything that the film makes after that.
4. This is not so great for filmmakers.

The problems that we're think about is:

• Why is financing a film so hard?
• Can we make this easier, simpler, more fluid?

The current difficulties are:

• Filmmaking is a risky market, people are afraid of risk;
• It's hard to invest in this industry;
• Film distribution is a mess;
• Movie theaters are a mess.

These above problems have contricted the people who can actually buy films or TV shows to big streaming companies, which is not great because there're only limited buyers in the market, and will lead to:

• Filmmakers are not in control of what they're making;
• Fans essentially become bag holders that are just getting dumped on at the end of the process instead of actually being at the beginning of it.

The solution of StudioDAO​

The solution of StudioDAO to these problems and the way it should be at some point in the future, is to turn itself into a new kind of social network that solves the problem of financing premium contents.

• Members pay to join the DAO;
• Members get to green-light the films;
• Members get to be on the inside of this process.

So this is going to create unprecedented freedom and opportunities for filmmakers and fans. It's a new voice at the table in terms of how things get made and a more direct relationship with all the talent they might care about.

The way that this business works right now and what StudioDAO can do in the future, can be really harmonizing. StudioDAO is going to build a system where we can partner flexibly with projects, whether they're just starting or they're finishing and just need a littile more money to get over to their green light.

The relationship between the community and the filmmakers, no matter where the filmmakers might sell the films, to Netflix or to theaters, the community participates in that and gets 30% of the revenue that the film generates downstream. So the community is not just green-lighting movies for their own consumption and enjoyment, they are essentially building the films into a part of the bigger community of StudioDAO.

By this way, it basically leads us to 3 different ways to finance:

• Sales of the retail NFTs;
• A community wallet that we're going to be funding at the beginning;
• Revenues from previous projects.

The film financing fund​

When we think about how the business works here in terms of the traditional piece, there's a way for us to actually create a more traditional fund that wants to play nicely with the rest of what we're creating.

You can imagine, if you had a US$5,000,000 film and you can sell $1,000,000 worth of NFTs, that should be a really good signal to people who want to put other money into the project, because it's appealing and there's people who are behind it. So we're trying to create leverage beyond where the retail market is for NFT's right now, because it's still early and the market is small.

There's a 2 trillion dollar entertainment market out there, we think that there's a clear scenario for decentralized studio that can do a billion dollars of production per year in three to four years from now. we're actually talking with some of the people who funded Kickstarter at the beginning and they shared that Kickstarter actually funded 500 million dollars worth of films in the 10 years that they've been in business. We all agreed that with Kickstarter not being focused on films and not having the benefits of everything that on-chain applications might be able to give us, I think we can shoot for 10x that in the next 10 years. Our target is five billion dollars over the next 10 years worth of films and content.

Legal struture of StudioDAO​

Disclaimer: This is not legal advice, I'm not a lawyer. This is what we're doing, but I don't guarantee that they won't get you in trouble if you do the same thing.

We have 3 legal entities in the US, two of them are Delaware LLCs and one of them is an Unincoroporated Nonprofit Association(UNA) in Nevada.

The StudioDAO UNA is the nonprofit that will become the million-people-green-light committee. This is the true DAO of StudioDAO, the membership of the community. It's the committee that is picking films, working on financing of films, managing the green-light fund and voting in the governance over the protocol. It's also the recipient of 30% of the participation of the contracts that we are sourcing for the UNA right now and we're sort of creating a legal structure to do that.

StudioDAO Genesis is the legal entity that belongs to StudioDAO UNA so that it can have certain kinds of bank accounts that UNA may not be able to have on their own.

The StudioDAO Backlot is a for-profit services company, it mirrors sort of the structure of Uniswap, in terms of Uniswap Labs, and then the protocol being a separate piece. Obviously we're completely different in almost every other direction, but the process of where you do the product development(the StudioDAO UNA), how do you do the things that have to happen in the real world (the StudioDAO Backlot), is how we're splitting at.

Projects on Juicebox​

1. The StudioDAO Backlot.

For the Backlot, the token issuance is 1,000,000 / ETH, while 700,000 goes to the contributor, and 300,000 is reserved for the projects owner.

2. The Unlikely Love Stories:

This is a real project, and it will probably be the first juice box that goes live when we're ready to go.

The issuance rate is 840,000 tokens / ETH with 50% reserved rate, so contributors will get 420,000 token per ETH.

The funds distribution will be 90/10, 90% of the funds will go to the project itself, and 10% will go to the StudioDAO Backlot juice box and generate more green-light power tokens that go back to the filmmaker in exchange for a 10% fee.

The tokens distribution will be 50% for filmmaker, 40% for the UNA and 10% for the Backlot.

3. The other two projects are all for educational purposes.

Juice newsletter​

matthewbrooks: So this is a really quick preview of the newsletter.

• Recap by @0xSTVG,
• Governance cycle recap by @matthewbrooks,
• Podcast episode by @matthewbrooks and @brileigh (if there's a new one),
• Tutorials by @nicholas or @filipv or someone else (if there's a new one),
• Recent articles on the blog,
• Town Hall recap by @zhape,
• Some links at the bottom.

So yeah, that's pretty much simple. It's just an easy way to recap everything happening on the content side and also giving everyone a chance to catch up with the basic goings-on. It's just to keep everyone informed and to also repurpose the content that we're making so that we can get more people to see it and hopefully get a better engagement with the content that we're making.

brileigh: Shout at @nicholas for all the feedback as well as @Felixander and @Sage for all the help for putting this together. And just echo as @Matthewbrooks said, a quick easy way to figure out everything that's going on within Juicebox without having to do the manual work to pull all the information together.

nicholas: I think this is gonna be great for getting better distribution or increasing distribution of stuff we're already producing, because I think a lot of people are consuming the Juicebox content that several members of the DAO are producing via Twitter and Discord. But to try to reach people who maybe not on Twitter or not in the Discord regularly, you can imagine, if there was a newsletter sign-up link on the website during ConstitutionDAO or AssangeDAO periods, some number of the people who participated in those fundraisings might have stuck around for the newsletter. So I think a newsletter is a really good experiment to see if it engages people. I really love what you did with the layout and everything, it looks great.

Legal stuff with @filipv​

filipv: I can give a brief update on some of the legal stuff that I've been working on with @tankbottoms.

In short, we set up some structures for MovementDAO, PeaceDAO and a few other entities that are building things related to the Juicebox protocol.

We created a number of structures that are similar to what StudioDAO did. We have two different Unincorporated Nonprofit Associations(UNA), one in Delaware and one in Nevada, as well as a few LLCs in Delaware and Washington for different intellectual property. We also put together a number of intellectual property agreements and things like that.

For the short term, we're just using these for these DAOs. If you want to check out these documents you can find where they are now on this website gov.move.xyz.

But what we're working at is templatizing a lot of the things for common use cases for Juicebox projects, and then letting people put in metadata about their projects and then having it spit out nice looking PDFs. There's like a lot of interesting stuff in here if you're interested in this sort of thing that we're hoping to to roll out to more people pretty soon.

Tiles.wtf by @filipv and @peri​

filipv: I also want to do an update on Tiles.wtf

For those of you who didn't see it, it's a rewrite of tiles.art but completely on-chain, so the algorithm to render the Tiles is completely in Solidity. The website is written in Svelte which is super cool because it lets people compile the components and use it with different frameworks if they'd like to. It's also a little bit more portable, so you could imagine someone setting up an npm package using different components or something else.

This website has NFT minting and mint pages as well as a fully featured Juicebox treasury, it doesn't have configuration yet. So you still need to configure on juicebox.money or another website, but for people who come here to contribute to the project, it's all working on this website. This is all open source and available on GitHub.

peri: I can talk on the Tiles project for a second. Tiles is an NFT art project that I put out about a year ago. It was actually launched on day 1 of Juicebox lifetime, it was Juicebox project No.2, next to JuiceboxDAO. The artwork is rendered using a server, so you can basically buy these NFTs but their artwork is rendered off-chain, which is not as cool as rendering artwork on-chain.

A few months ago @tankbottoms came in and decided to try putting the artwork on chain, and he did. It's amazing amount of work that he did to get that working. I don't even know why he wanted to, he just did. So big shout out to @tankbottoms, I wish he was here now.

And @tankbottoms went ahead and deployed a new V2 of the Tiles NFT contract a couple days ago. So it's live now at the Tiles.wtf website. There's still some things that are up in the air right now. The main thing that I'm concerned about is that I really want everybody who has the original V1 Tiles tokens can get the same Tiles. Tiles are denoted by a wallet address, a 40 character hexadecimal string. I basically want to make sure that everybody can get the same matching Tiles, and the V2 token that they have for their V1 token. There's a chance that the contract will get redeployed to make sure that we can settle those balances, airdrop tokens to people or make them claimable as needed. So there'll probably be somemore updates coming in the next few days, @tankbottoms and I are chatting on some of that stuff.

filipv: There's a seizing functionality on Tiles.wtf, so someone mints the Tile that corresponds to your wallet, you can mint that Tile and take it from them. And the same is true for the V1 TILE token. If you own a V1 TILE and someone mints a TILE with the same address, you can mint that TILE and claim it from them, for free. @tankbottoms and @peri are thinking about a new price revolver for the contract, so there might be a new contract soon. Maybe chill out for a few days before minting.

peri: Yeah, I would say hold off on minting any Tiles in the website for now.

filipv: One last thing, the Tiles.wtf repo has a new license on it which basically says that people can only use it if they're pointing revenues at a Juicebox project. It's a little experimental license, but we're trying out some funky stuff to make licenses for a code to do interesting things.

Protocol data by @twodam​

Dune dashboard update​

twodam: Here is the main dashboard for the Juicebox protocol.

If you scroll down a little bit, you can see the section called period so you can select different periods.

After you select the period, scroll back up and click apply all parameters, and all the stats will refresh using this new period.

Basically we are using the page to do the weekly reporting, so you can see there is a value new projects and active projects in this period.

There is the trending projects:

You can see many links in blue, if you click the See more, it will take you to the related dashboard of that project, with the overview data, like how much total raise, how many tokens and how many token holders in that project.

And on the right bottom of that project page, there's a small logbook where you can see all the actions taken by people there and all the payment Memos if there is any. And you can click all the links, they will take you to the relevant Etherscan pages of those transactions.

Zeugh: What's the meaning of Fully Diluted Valuation here?

twodam: It's the value that equals to total token supply multiplied by market price.

nicholas: By market price, do you mean AMM price or which price?

twodam: If they have an AMM price then it will be used, if not, redemption price on Juicebox protocol will be used instead.

And back to the protocol overview payge, there is this All users If you click the See more after an ENS/Address, it will take you to the dedicated page of that person/address. Let's take @jango's as an example:

jango: Man, I feel this is full-fledged superpowered graph interface for projects. I wonder if we need to build a documentation on how to navigate this into the info site or Juicebox High or something? maybe in a more tucked away Data section or something?

twodam: Yes! I would love to.

One more thing, if you scroll down to the bottom of the protocol overview dashboard, you can see the the current trend of the ETH in the whole protocol.

Twodam's complete Dune dashboards are here.

Juicetool update​

nicholas: Can we also look at Juicetool?

twodam: On the front page, we click the Snapshot Plus at the bottom, we can go to the voting info page. In the middle of this page you can see the Status. That's where you can filter by active, Haven't voted, or Under quorum.

jango: @twodam, the frontend chops are fantastic, this is looking great. You've been constrained by the Dune UI just writing queries, and now actually refactoring the interface elements is a huge unlock, this looks fantastic.

twodam: Thank you, I'm still learning.

On the bottom left of each block, you can see the "jump to" symbol, which is basically the place you can click and do a quick jump to that specific Snapshot page from here.

jango: We need to figure out how to make sure that people starting their projects know this is here, and that they feel good about it. It's obviously useful, but I think most projects starting up need to orient governance around and all the things. What a luxury.

nicholas: You can vote from within this interface also.

Zeugh: Oh and it shows a green active if there is a proposal up.

nicholas:So to clarify, is that the list of spaces to which you are eligible to vote that you have voting tokens?

Zeugh: No, to which I joined. The ones I really enjoyed. I can't vote on Gitcoin, but I follow it to see what's going on, so I get to see it.

twodam: If you hover above active, you can see how many time left for you to vote. And if you have voted for this proposal, you can hover above voted, It will show which option you have voted.

nicholas: There's a feature for whether proposals are have met quorum yet or not, next to where closed. If there were active ones, you can sort, for instance, by haven't voted which means that the connected wallet has not yet voted on, and add Under quorum to see all the proposals that you have not voted on and they have not met quorum yet.

So I think if we zoom out a little bit, like this Juicetool plus what @jigglyjams is doing with Nance and some other initiatives altogether are like a suite of tools. Also think of the on-chaining stuff that we use for multisig. These are like a suite of tools that all the projects on Juicebox probably gonna need, given at least the most popular configuration for multisig, snapshot, DAOs. So I think this kind of stuff would be great in Juicebox High on how to set up. Possibly also build a version of Juicetool that the people down the road could deploy specifically for their project, so it has a dedicated URL and only covers their DAO's needs. It's really cool to see you do this. @twodam, when did you start doing front-end dev? When is your first line of HTML?

twodam: Oh. Maybe a month ago.

jango: The user experience of tying all these tools together, making it easy and obvious for people, giving them the understanding of standard and safe tools that should be used, it's fun to figure that out once all the pieces are in place and work our way to something more optimal over time. But you can just pass around links and they are hosted in all kinds of places for now, it's a good start and so useful, especially for weekly multisig stuff all the way through.

JohnnyD: Yeah, definitely came to figure out how we can to streamline this and connect them all together, so if someone new to start a project, they can have access to all these tools in a seamless environment. But yeah, as you said, it's gonna be interesting to figure out the users experience side of that.

jigglyjams: Yeah, totally. That's been on my mind lately, too. I could imagine, as long as we're still relying on Snapshot, in the project creation UI, you could just check a box and create a snapshot space, and we could send a transaction to create that. Along with that, we can add Nance instance once it's at that level. I'm working on submitting transactions for @twodam's Gnosis Safe payout changes. I want to work with @twodam to have Juicetool be the frontend. if possible. I can see that being really beautiful. It looks amazing, @twodam. It's been super cool. I watch you develop it and excited to see more.

The One Hundred Thousand Million Contest by @Zeugh​

Yesterday there was a Hundred Thousand Million project of sustainable City based in DAO structure in Chile in Latin America, reached out to me to do a partnership with Juicebox.

They're trying to get attention of nice projects around web3. Because they're building a city and they think that building a city of the future is supposed to have creative people creating awesome stuff and they see Juicebox as one of those spaces, so they wanted to do a contest for giving a prize for a Juicebox project. They reached out to me to help organize that and we put out a JokeDAO contest which is going to start tomorrow，giving out 1 ETH to a Juicebox project that gets more votes. They're opening the contest tomorrow. Everyone is welcome to submit a Juicebox project and go to their Discord server to get tokens to vote.

Two truths and a lie by @Felixander​

The correct answer is ... Zom_Bae The lie is the one about an albino rat.

Review of JuiceboxDAO x Morganstern's Ice Cream event with @Zom_Bae​

Zom_Bae: I feel like the way we had it set up as Juicebox headquarters was fantastic. It was very nice for us to have one place to come together every single day and we know like what hours we were going to be there. I like the free flowing aspect of it where you know people who just come and go. For most part I think having projects running on Juicebox having the opportunity to post meetups was fantastic.

I think one of my biggest takeaways from it is that while we all kind of get to know each other by working together over Discord, Twitter or whatever it may be, I think getting to meet in real life and in person is invaluable. And this didn't necessarily start as like a Juicebox community meetup, it's kind of how it turned out and I'm glad it did. I think it strengthened a little bit our bonds and we created some. I think that was pretty magical and pretty special. I can't wait to do one on other continents so we can spread this Juicebox fan vibe everywhere. That was super cool.

I think there's a couple of things that weren't considered that we'll learn like through the process of doing it. One of the biggest things was the space isn't conducive to shitty weather. The weather was absolutely perfect the whole time we were there so our outside space was phenomenal. I think that's something we should take into consideration if and when we decide to do other events, I think that's a big one actually.

And then also it was just really rushed. The fact that we pulled this together in less than a month is pretty incredible. And the way it went so smoothly. It's pretty pretty dope got to say.

Let's see, a couple other things like I think just the short time span to get it all planned. Programming could have been a little bit better and I take full responsibility of that, but I think overall it's a fantastic event. It's got me chewing on this idea of what I've been spitting out as calling them like "unconferences" whether it's like NFT NYC or like the ETH conferences around the world. Just wear Juicebox clothes and plan something a little different so we can bond over fun things like cooking classes or we can go learn how to like surf or you know, jam sessions around a campfire because inevitably we're going to talk shop. It's like even when there were like meetup hours ever still was drawn to certain conversations and building and creating and how to make you know JuiceboxDAO Juicebox protocol the whole ecosystem better. So I really kind of like the idea of it if that makes any sense.

nicholas: I was really impressed. I think it's really cool that Juicebox funds a multi-day phase where Juicebox projects with smaller budgets can just create a little event without booking it from advance or too much prep. I think that's a really cool model that we discovered through this experiment.

Zome_Bae: A hundred percent. I wish more people took advantage of it, but being the first time and during quick time span. Yeah, I appreciate that a lot, too.

nicholas: Yeah, exactly. I think it's super powerful if there's enough density of Juicebox projects in a place. I think that's a pretty worthwhile governance proposal to fund to reserve a space that anybody can just come in and grab a slot. That's really cool.

Zom_Bae: Yeah, since you mentioned that I don't know if anybody noticed the Juicebox events project that I created right before this event. That's kind of the what my vision for that project was. I don't know I gotta think it out a little bit more but instead of trying to fund these project or these events all at once, you know, thirty thousand dollars was a lot for ice cream. It's something where we think this is worth doing to just pump a little money in every funding cycle. So it doesn't feel like such a big hit.

jango: Yeah, I feel really great about how this one played out. I think it's certainly something that was really interesting to see and the momentary aspect is awesome. I think ice cream sets a really cool tone, I think New York City set a really cool tone in that particular block in the city. It's a really cool tone Danny absolutely crushed it. And I'm excited to figure out how to support those and evolve those at the moment, but it's also going to be interesting to see what we do with everything that we dreamed up or felt or did in that moment.

Zom_Bae: And yeah, I had more than a handful of people. I think I just have this vibe like she doesn't know what crypto is. I'm not done people come up to me who are new to the space and we're just kind of timid but felt so comfortable around our group. She's like that people are just like everyone here is so nice and welcoming a couple of people.

I think it's a testament to our group of people and but that also actually reminds me of one thing in conferences like that. We should have better way to disseminate information not only for people completely new to web3 or crypto, but also for people who know the terminology and know all the technical aspects of it. Just finding ways to onboard the beginner which I know Juicebox might not be the best thing for beginners, but we can do it. I know that's the thing we can do so having whether preparing QR codes to send them to the educational tools whatever it may be. I think this will come into like the marketing realm and strategy realm down the road.

Kentbot: So it was fantastic and just as like someone who is launching projects having a place to just hunker down and be at home while you're trying to do it was super fantastic. So, thank you to everyone for making it so great and Zom_bae on the stage.

I got a text from Nick a couple of minutes ago, and he's so excited about the whole thing, he wants to actually take all of the flavors that we made and put them on the website and make them like actually permanently the Juicebox collection becomes like a part of what's for sale at Morgansterns. So I think that's super interesting just in terms of us starting something and this is now gonna have like some perpetual aspect to it. So, you know, we'll figure out what that means， maybe we can make like a buck a pint or something and put that into the Juicebox events and start to get like some money coming back into that. So maybe events could make money for us, like maybe at least cover their own costs.

Zom_bae: Yeah. For sure. Let's plan. That's so exciting. I'm glad he thought it went well, I didn't get a whole lot of time to talk to him because he was insanely busy. So I'm glad he's stoked to keeping on with us. That's great.

jango: Yeah, that dude's is seemed just eager to just get the ball rolling on crazy shit which is really exciting. And he leads us to a big wild ideas and is a very just get-shit-done like strict dude in person, which is a fascinating balance that he's of course.

He created a hell of it, we can make up like any flavor and I think from his perspective thinking about what a Morganstern's community funded ice cream flavor like monthly or whatever would look like and maybe certain cut of those sales go back into the community treasury, so there's like some incentive for the DAO to choose appealing flavors or wild flavors or whatever be a wild endgame for this stuff.

Zom_bae: jango's dropshot was the first one to go every single day. I was shocked. I think there was no way people were gonna order that, but they are gone.

jango: I was nervous. I wasn't sure like the day before it dawned on me like damn y'all, the shenanigans just don't resonate in real life like we've just been playing in crypto Twitter and Discord land.

Zom_bae: But yeah. So as everyone who was there you know has more time to think about it after this initial feedback there in the town hall chat. There's a link back to the notion planning doc and at the very bottom if you guys have any thoughts or feels about anything at all. The events moving forward, whatever it may be definitely throw it in there. There're cool things coming.

DAO NYC and DAOPlanet reveiw​

jango: DAO NYC was a good scene. It was very panel driven, so there were a few rooms and like a five-person panel with a topic and I was part of a fundraising panel.

It honestly kind of felt like live Twitter, because someone would ask a hot take question and you'd go around just giving the hot take answer or whatever. And it's like bite-size chunks, but it was like facing out towards the crowd and folks like lounging around sitting around.

But it wasn't the same tone as what Juicebox's had which is like casual in the street hanging out, it felt a little bit more put together tight, like you check in and get a badge and and go up and have strict time frames for things. But it was really well organized for what it was. There were some builders as well as a bunch of VCS around and folks from various maybe sponsorship perspectives too.

As far as our involvement, I think the panel was cool. I'm super down to to do these panels every now and then. It feels just kind of like talking to folks on Discord, but you have a very constrained amount of time and you're not totally chilling on the street where you can just keep bouncing an idea and growing an idea for indefinitely, instead you're kind of stuck to a little talking point. I know a lot of folks did it at the DAOPlanet one too. I'm curious what your thoughts were and how it feel for y'all, but I think a lot of the impact we can have will tend to be like in real life over time.

Each of us being able to meander around and talk to folks that come from different perspectives and different backgrounds approaching the space in their own way and finding like how to meet them where they are and then take them to to like a point of view that that you have is going to be increasingly more important. Stuff like this might start happening with more frequency or not I don't know, but it's a cool thing that everyone should take up the opportunities if you're available to expose if you feel like it.

And then the amount we paid for, it's kind of feel paying or sponsoring that stuff for me kind of like giving back to a lot of the ecosystem, because a lot of folks from around the ecosystem are hanging out there that day and it's cool just to be a part of the ecosystem in that way. Is it very efficient for for JuiceboxDAO itself directly? Maybe not, or not as much as ice cream felt to me, but it felt like a worthwhile thing being in the conversation in that sense, but it's something I would actually approach with a little bit more critically next time.

yeah, I don't know I think like apart from the fact that we sponsored that allow us this panel seat, which I don't think is particularly valuable. And so the event was just like finding the people that you want to jam with for a bit and then duck into a corner and do so.

It's cool to have a space where that shit can happen too, right? I don't know what exactly I would do differently like I know the folks that tally were great and super cool to hang out with. I trust that they're also debriefing and trying to evolve that scene. But I think out of priorities, the only thing is to double down on what we did with ice cream and approach more ecosystem routing out contributions to the ecosystem with a little bit more caution.

Zeugh: I'm just super happy that you guys are having those events because sometimes they're not about conversions in the end like actually get into projects launched, but they do go a long way in getting the ideas and the visibility of Juicebox, but also of the ideas that we're having here going further.

seanmc: Alright, I just wanted to hop in and thank you everyone so much for giving a grants to jokeDAO. We're like super grateful and we're gonna make awesome stuff and I'm gonna be in the Town Hall and I'll show on what we're working on too, but super excited and super grateful. So thanks so much.

Actually, we have a little bit of alpha if people want to check that out. That's our V2 UI that will be releasing maybe in like a week or two weeks. But yeah, I can definitely give updates at any point.

NFT rewards​

jango: We're just writing that contract and we're just refining how it's organized to try to reduce the number of transactions necessary when you're launching a project to just to the one to deploy your NFT and the other one to deploy your project or reconfigure your funding cycle or whatever.

And so that should be wrapped like my goal is to deploy the contract piece of it on Friday. I think it's becoming more of a stretched goal, but once these steps taken, we're all ready to finalize wrap-up, review and document. That's where all my attention is right now. And I think the UI with its leveraging a cloud function that @tankbottoms wrote to actually create the metadata or something. Maybe @aeolian can step in here or someone from front end.

aeolian: Yeah, I'm a little bit behind on the NFT stuff. As far as I'm aware, @tankbottoms and @JohnnyD are working closely, @tankbottoms basically built a cloud function to handle the uploading of IPFS stuff. And then Johnny is working on the UI on the actual Juicebox.money website. I think it's going quite well, I think just with the NFT NYC everyone's kind of like scheduled to be kind of back on deck the last couple of days. So let us check in and @Kenbot will certainly reach out when we have more updates.

jango: Yeah, I'm feeling really good about like this NFT rewards thing that was a big takeaway for me from a lot of the conversations we had. I talked Nicholas a lot over the days there and there might have been a few misunderstandings about how things were working like the underlying bits and what we were striving for. But I think this week is the week to really get the core of this knocked out and feeling deployable.

Kentbot: Awesome, so when you say deployed that's basically it'll be available on Rinkeby and then we're gonna test and play around there or like what?

jango: that's a good idea. We should just do a Rinkeby version, but it's all tested, right? we've written tests so theoretically it should work fine. So there won't be a lot of rinkby to mainnet delay. The biggest delay is probably just gonna make sure that we have the messaging right in the front end and that we're interacting with things correctly. And so if the contracts go open Friday, then we maybe have in like early next week to bounce the front end idea around maybe all hands on deck from both front end and contract side. But I don't think there's like a Rinkeby play time like the contract is pretty formalized already or ready by the end of the week.

Project Handles​

aeolian: Yeah, I can definitely talk to that. So yeah the status of project handles contracts all the contracts side of things as being deployed. So that's really awesome. The current hang-up at the moment that we're kind of tossing around is how we handle the routing on the front end. So the routing on the actual website how someone actually what URL our projects eventually has. I don't know if a few people across the group here have been involved in those discussions. We're pretty close to coming to a reasonable solution, but anytime we're talking about routing, it ends up being quite a sensitive topic because there's a lot of edge case considerations that we need to make, so yeah, it's definitely close. Also Peri who's leading that is sick at the moment. So it's definitely still happening. Hopefully we can get something together by the end of the week.

jango: oh, yeah, it's it's delicate for sure. And the V1 to V2 contract stuff is deployed earlier today, which feels like that's a wrap from the back end thing and I think last we saw a preview from front end that's also looking pretty promising to go out soon, which will be a big step in our migration process.

aeolian: Totally. Yeah, that's another thing on the front end agenda for this week very big couple of weeks in front end, also this last week has been kind of big as well regarding some kind of security things which we're currently talking about on this town hall, but yeah, it's been it's been crazy couple weeks.

Namecheap Hacks​

aeolian: I can definitely talk about the namecheap stuff as well. So those that weren't aware, Namecheap is the domain name provider that we use and many many people use in web3, but also beyond web3 as the host for their domain name. That's where juicebox.money lives. So they were actually compromised, in a way that is essentially a DNS hijacking. So Juicebox wasn't affected as far as we can tell but there were a few prominent DeFi projects that were affected. Fortunately for us and other people, the namecheap CEO and the team in general is pretty reacting quite well. They actually coincidentally in the last few months released a premium product where we can isolate our DNS from the kind of generally used DNS service that namecheap offers. So we've upgraded to that, and we're getting that free of charge as far as I can tell which is great. But yeah if you see any rumbbling about that on Twitter, that's what it's about. And yeah, we'll probably be doing a post-mortem on that as well. Well, yeah as far as we can tell Juicebox wasn't affected.

So basically we discovered a vulnerability inside, but it doesn't end up being quite impactful for the website. So we use a service called pinata for pinning our IP address starter and that is essentially how we upload project details and project logo things like that. So we paid for a custom gateway for that product and basically the end result is that because we're exposing our API Keys someone could basically unpin project metadata and that would mean that projects are basically unavailable on the website. Of course, they're still fully on chain, and nothing's affected there, but it just means that they wouldn't be displayed like when you went to load the project page nothing would come up.

The remedy step is basically that we would go ahead and re-pin all that project metadata using our custom gateway. But yeah, the end result is someone could basically write a script to take down every project off the website. And so that's pretty bad. So we acted quite quickly I'd say, but essentially now we are using our own API server for the pinata stuff. So it's a proxy server where we're not exposing any API keys and the IPFS unpinning functionality is not available from that service. So basically that vulnerability has been mitigated. It's worth noting as well that no one has actually exploited that vulnerability. It was just something that our team found internally. Yeah, please look out for the post-mortem on that coming in the next week as well.

nicholas: and I'm just curious as the last note on that. Is there any kind of duplication that data because if they had been un-pinned I presume that's the only copy. Is anyone else pinning that data because if it happened like would there be another copy anywhere of the project metadata?

aeolian: No, when you pin the same data, it's going to be available at the same content hash.

nicholas: Is anyone else pinning it are we pinning it on a node process on AWS or something or or on someone's local machine.

aeolian: I mean it's still living on IPFS. It's just instead of pinning it on the client browser but pinning it via our proxy server.

nicholas: I wonder if it would be worth having a second copy some other process pinning it, just in case anything would ever happen to pinata.

aeolian: Totally, it's it's a really good consideration, there's definitely some redundancy we can build into a pinning process for sure.

tankbottoms: And we have copies of all the pins on our firebase function.

nicholas: Oh, nice. Cool.

jango: Sweet thanks @aeolian for recovering that. Was that exposed during the trending solution that we had that at one time where the front end would pin like recently downloaded list or something? For efficiency.

aeolian: This particular thing has like those API keys have been exposed from JuiceBox. Yeah,

jango: Well bummer and grateful. No one did a thing and grateful you all did a thing. Thanks for recovering and bringing it up for future folks to be wary of.

Bookkeeping work flow with @gulan and @jango​

jango: Yeah, I wanted to introduce you @gulan's section real quick. Just saying with all of this movement from V1 to V2 and movement of funds into the multisig to manage these larger scoped efforts like these events and these audits or bounties. It's like the bookkeeping role in keeping these things tight and allow multisig to execute stuff with confidence is like kind becoming a little complex it seems and I think @gulan is like the reason that things can manage to happen on these tight timelines still.

So yeah, like I was thinking about proposals and well, we're probably trying to do some walkthrough of the life cycle of proposals to bookkeeping to proposing aggregate reconfiguration onchain to multisig's signing, because the last time around there's slight gimmick in that process at the very last minute and we had to overwrite a transaction and we got it in just the nick of time. So be sweet if we all understand and recognize the process and then obviously work to automate it away via tooling.

gulan: I will start out by saying is great meeting and seeing all of you last week for those that were there. That was amazingly educational event and very happy to have gone. It was great to see you all.

So I'll start this by just doing a brief overview of kind of my process that happens on a per cycle basis and that always starts with proposals. We have that first two days of releasing the whole governing cycle. We have the first two days that kind of people actually putting the natural language of their proposal and maybe there was some type of edits that we need to make to make the actual proposal executable whether that be for our governance process or for actual funding through funding cycle.

(sharing screen)

So, you know just going here reading every proposal making sure it's executable or not is the first step. So moving forward keeping that stuff really tight making sure that there's no ambiguity for two different people to be looking at the proposal to kind of come with two separate sets of conclusions on how to execute, is what we're trying to achieve.

The second step is actually making a snapshot review document. So this is kind of putting all of the proposals and the configuration assuming that they all pass and having one where assuming that they all fail and this is really good to put down into writing because it illustrates exactly where the money should go or at least to my assumption of where the money should go.

And so that way when we get to the third step which is actually draft a config file. We've already had the community take a look at bookkeeping at least for two or three days to get the right idea from there. We finalize the config file and we save it into the Google Drive and then the final step is to actually add each individual line item transaction to our accounting sheet and I try to convert the natural language of someone's proposal into an actual machine readable line item, which in the future we can totally automate from. But some of these columns are very easy. So anything new that pops up, I just add a column to the right. I try to make sure that allow for as much flexibility in the proposal stage as possible and I use the sheet to to convert that into some type of machine readable thing for historical data to actually see kind of what the payouts were for an individual, going back to the first funding cycle. I keep this USD pivot table and this is just a manually created cell by cell pivot.

The one kind of big hole that I'll touch on here real briefly that we're in the process of discussing is the actual multisig payouts. I'm not sure how deeply I should dive into it, but when ETH was going up this wasn't really an issue because when we allocated budget towards a particular project whether that was in US Dollars or in ETH as long as the ETH price was going up, we always had a budget. But we're now kind of in a whole different world where we've allocated ETH that represents a US dorrlar amount that ETH no longer represents now. So, this new world, I guess of us being a little more cognizant of that we're gonna have to do more detailed in the proposal stage. I'll definitely keep an eye out on that.

And then the two kind of takeaways that I have on my plate to reduce this problem. It's my understanding that most people don't understand how the bookkeeping process works and how funds get denominated into US dollars. Obviously when you put money into Juicebox you put in ETH and then we pay it out in US Dollars, so for these one-time payments that are in US dollars, it's kind of confusing. So I'm going to make a document that goes over the process and how we should kind of unify this process moving forward for US dollar payouts.

Yeah, so I think number one, I'd have said for my vantage for in terms of risk, I feel kind of weird doing the bookkeeping and potentially sitting on the multisig just because of like legal concerns, I think yeah.

I mean if there is a way for me to submit payments after like doing some type of natural language or if we can automate all this stuff away, that makes sense to me. I don't know how to do that. But if there's a way to make it a JSON and somehow easier for Juicebox to process. I personally like having the stuff with @twodam because we have submitted a proposal and then someone else review it while they do the config. That to me has been a very sure way to make sure that no mistakes have been made but there's always room to streamline it, I guess.

jango: Yeah, I think both the things that @filipv suggested are goals that we're striving towards. I think we're making baby steps and understanding very tightly stretched proposals, which is that what we've just recently solved in some sense. We've created processes for them. The end game is is for sure to leverage Juicebox tools to better make the stablecoins and ETH positions, that's not like something you have to prioritize because we have manual solutions for now. But it's for sure a goal and going through these steps that @gulan outlined. I'm going to put a link to one of the current transactions that are pending, and we can kind of look at how it structured.

The front end actually submitted it to the blockchain and for me it's almost the end and I think the name of the game is just go from spread sheet to that formatting automatically. So this is a list of all the queued transactions right now which a little bit of multisig after this call to discuss on the docket here and tease out the details to make sure we're signing the correct things, but if you take the 133 for instance, open up 133 the data. This is configuring the V1 JuiceboxDAO treasury and you can see the the parameters and the values there and at the end you see payout mods and then a bunch of objects in an array which are how the payouts are formatted here. It's quoted in a percent so there's a few things that we have to get right going from your model to this. But like right now the fragile point that we're trying to make sturdier is like a human effort to have to parse all this and make sense of it to approve it when intuitively we're just gonna trust that whoever is putting up the transaction and sending the screenshots over are submitting the right stuff, but we should have algorithm to like verify.

gulan: Yeah so I can tell you that pretty much the data in this format seems really easy, I mean, I don't want to speak too confidently, but from the conversations that I had previously, just bringing in data from Snapshot and Notion which was building an automation for that. It required a little bit of structuring and I got pushed back initially for trying to fully structure all of that input data because it seems like we could definitely structure at least 90% of cases, put it through a simple machine like the accounting set that I set up and have it export into it config file like this like it seems very very doable to me if that's the end state that we're looking for to kind of automate these steps away. I'm very happy to let the needle more in that direction for sure.

jango: It's definitely gonna require the effort to manage stuff because now we have like many transactions here, right? We have transactions going to the V1 treasury to reconfigure it. We have transactions going to V2 treasury to reconfigure it. They both have unique parameters, and obviously we're tending towards the V2 sides slowly. But in the meantime, there's just a lot to juggle and if we can one thing out of time to find ways to automate I think we had at least like just the V2 stuff again. We can even put pressure on ourselves to move quicker by just automating stuff and then eventually plug it into Nance so that all the way from notion we have some weight format language to get all the way to the config file if everything is approved along the way.

nicholas: I think beyond some of this process details that it's probably a little mind numbling for people. I think broader issues that there're some challenges that as you said have become apparent in the DAO market with the way that funding cycle configuration works and particularly from the perspective of someone writing a proposal, it's not clear how to write a proposal to be totally executable and perfectly specified. So I think we're gonna have a meeting probably tomorrow or the next day ideally with @twodam in the picture as well. I'm time zone wise and hopefully we can sort of come to some solutions that make it easier because basically if you're making a payout if you're doing a payroll payout the funding Cycles are USD denominated and so, you know giving contributors getting a thousand dollars and then the price of ETH fluctuates, and they get a thousand dollars worth of ETH at its new price. That's fine. But if you're doing a funding cycle configuration to pay a specific dollar amount and the price of ETH is fluctuating and it can actually be a real problem. So we've seen this with a bunch of proposals in the last cycle specifically the bug bounty ones. There's all this like weirdness around USD denominated grants to Juicebox projects like BuidlGuidl and jokeDAO like we're denominating because the funding cycles are denominated in USD. We're saying we're going to give $20,000 or $40,000 to Juicebox projects but ultimately they got paid out in ETH. There's something a little bit weird like a mismatch between we might as well just be allocating to projects based on ETH, but I think there's some protocol limitations here that we're pushing up against. But it is a bit of a mystery from the proposal author perspective. So hopefully we can come to the best system.

jango: I think a lot of the issues are like in this V1 to V2 transition. We were utilizing the multisig quite a bit and with these bug bounties we're not just paying out the Juicebox projects, but in normal circumstances even with BuidlGuidl in Juicebox and jokeDAO, I think the answer is more put funds from V1 treasury into V2 and schedule payouts in V2 to those treasuries. We should be paying USD denominated ETH right? And I think the functionally correct thing that we're doing is paying USD to denominate ETH at a particular point in time. At that point that project can do with it what it wants. But if it happens if there's an intermediary step then you lose the fidelity of what USD denominated ETH is like at what time. If this synchronizes three transactions within a small scope of time to distribute fund from V1, dump it back to the V2 treasury and then in the projects treasury to do the conversion, if we were to specify sending USD to someone then we can't do it through Juicebox directly and then that swap should happen. we should move towards doing so automatically building the tools for that. But it's gonna be imprecise for a while. Let's do the best we can.

nicholas: I have two questions for you. First one is at what point is the exchange rate between a USD denominated payout and the amount of ETH being transferred, is it decided by oracle when someone hits the distribute button?

jango: Yeah decided at the moment of "distribute".

nicholas: okay, so because there is one perspective where there's like a two-week delay between when temp check proposals are frozen and when funds are actually distributed, but it's actually not that bad because the oracle establishing exchange rate at distribution time. So there's potentially like only a few minutes lag even if you do need to swap the ETH to USDC as long as you can get the multisig signers together right after the distribution. However, in V2, you're saying it's not possible to do USD or stablecoin payout directly from a funding cycle.

jango: We'll get there.

nicholas: Okay, it's down the road. Because like one thing that @gulan and I noticed as we were dealing with this like it really does require a full-time bookkeeping person to manage a complex funding cycle payout

jango: Absolutely.

nicholas: all right, in the first example, we're trying to get ChoiceDAO to choose Juicebox, and from their perspective, it's going to be a hard sell because if they're able to perceive some of these problems like they're already gonna have to deal with a multisig on Juicebox in some way like just added complexity like obviously that's feature also. For people who have like ukraineDAO chose Utopia payroll system on top of the gnosis, if we don't make it easier to manage bookkeeping, I think that's a dangerous comparison that perspective projects will be making.

jango: Very much on the same page, but we'll figure out if there's a priority for right now or are we trying to ship NFT rewards and stuff like that. The way to solve that is going to be through standing terminal and just routing funds between your treasuries and running payouts for any levels the terminals.

nicholas: It is conceivable to have a funding cycle configured to do both stable and ETH.

jango: Yeah right, you'll still just have one funding cycle, but you'll have any number of payment terminals that you can store funds in and have your community redeem from and pay to. And then make the payout from your treasury to addresses and to other Juicebox projects. We can imagine the payout to your other currency and in that distribute transaction that you're moving funds over. And then Juicebox can schedule payouts out from there. We'll get to the point where we can actually codify these proposals, but I think for now we just have to simplify the proposals and just deal with the trade-offs.

Front end updates with @aeolian and @peri​

@aeolian: It has been a while since we gave an update, quick couple of housekeeping things on what Peel's up to. So for the last few funding Cycles, we've been operating in two experiments, which has been really great. These align with the Juicebox funding Cycles, I'll drop a link in the town hall chat for those who haven't seen it before. So we're basically scheduling issues every two weeks that is aligned with the JuiceboxDAO funding cycle. And I think what we're going to plan to do is to give a recap of the previous funding cycle every two weeks. So next week, we'll give a recap of all the stuff that was done in the last two weeks, which is going to be really really great this time around there's been so much done. So definitely don't want to miss that.

I want to highlight one quick fun feature. That was merged yesterday. So this is the ability to add Banny stickers to Memos, which is a small thing, but potentially a fun feature which some of you have been enjoying. So thank you for everyone who worked on that particularly JohnnyD who led the implementation. Check JohnnD's twitter for a video demo of this.

There's four big things in flight at the moment. And I'll list them out in order of the time that they'll be shipped more or less.

1. The first is giving projects the ability to relaunch on V2 and giving token holders the ability to migrate their tokens to the V2 project.
2. Second is V2 project handles, which is being led by Peri. Right now projects on V2 don't have handles like they did in V1 so that is adding support for those.
3. The third is NFT rewards for projects. Essentially it's giving projects the ability to specify like if you contribute a certain amount of funds to this project, then we will reward you with an NFT. So that's going to be really exciting giving projects another avenue to get funding which is great.
4. And then the fourth is obviously veBanny and staking.

So I will quicking give an overview of what's in store with V1 V2 migration, basically we need to give V1 projects the ability to relaunch on V2. So the canonical example is juiceboxDAO. We're a V1 projects. We also now have a V2 project but none of our funds are in the V2 project.

What's gonna happen is the projects will re-launch on V2, JuiceboxDAO has already done that so we have a project on V2. They're then gonna move their whole balance to the V2 project. They're going to add another payment terminal to the V2 project, and this is a special payment terminal where it'll accept a V1 token and then return the V2 token in a 1:1 exchange rate.

So basically if I have Juicebox V1 token, there'll be a place in the interface to go to swap my V1 tokens for the new V2 tokens. And that's pretty much it. So the contracts are more or less done. Thank you to jango Dr.Gorilla and whoever else worked on that. That was really quick turnaround. And now it's pretty much up to the front end to get the UI done for all of what I just explained. And then we'll finally have upgrade path to some V1 projects to get on V2 and use all the cool new stuff.

@peri: I think as everybody knows we still aren't supporting project handles for the new V2 projects. And this is basically just has to do with some of the changes that are made in the contracts. We used to store a handle for a project on chain and it requires a lot of extra finessing in the contracts because we had to make sure that people can use the same contract and that handles could be transferred and reserved for certain period of time and claimed, there's a lot of functionalities to bake in. So with the V2 project contracts, we just skipped over all that because it ended up not being very necessary for the functionality of the contracts themselves. But the downside of course is that it's really nice to have in the app to be able to look up projects and search for projects.

So we've been working on another layer, another contract to add into the existing contracts that will support handles for V2 projects. It is not quite finished and it's not on mainnet yet. But we do have everything kind of functionally together so I can give a demo of how it'll work in the app and explain how it works pretty quickly.

(screen sharing ongoing)

So I've got this empty project here on Rinkeby, ID 4117. And we are going to set a handle for this project.

We've got a two-transaction-process for setting a project handle. And so the way that this works is we decided to use ENS names to handle the uniqueness of project handles what I mentioned earlier for making sure that handles be passed around and exchanged. There's a lot of complexity there that ENS has already solved really beautifully and so we built the system around ENS names. The idea here is that if you want to use a handle for a project you will need to own the matching ENS name. So for example, I just got this ENS name on rinkby testinginprod.eth and this would allow me to set the handle of this project to testinginprod. So I'm gonna do two steps here,

1. I have to own this ENS name first of course, I'm going to set the ENS name testinginprod.eth and this would be one transaction. Once this completes, step one will be done.
2. The next step here is to actually set a text record on the ENS name. So if anybody's used the ENS name app before you'll know that you can come down and set these text records for any number of different things. We are using a particular key "Juicebox project ID". You can come and set this property in the ENS name app manually if you want, but that's a little bit of extra work. So we've made it nice, pretty and clean in the app and you can basically come down here and click this button and we're gonna set that value in the ENS name text record to the ID of this project. So this one is 4117. So I'm going to send this transaction, which is the same as if I just came over here and just manually put 4117 here. That'll show up here if you got the handle set up.

Most importantly that'll allow your project to be searched on the projects page. Right now the search bar works by searching for project handles and V2 projects don't have handles you can't search for them. It's very lame that is now a thing of the past as soon as you set a handle for your project. Your project will be searchable.

An important thing to note is that either of these things change, for example if you were to transfer the ENS name and someone else changes that text record, your handle will go back to empty. So you have to have both of these things set constantly or if you were to change this to some other ENS name, your handle would go back to empty.

Another fun fact is you can also actually do subdomains here.

We will hopefully have that on mainnet this week. I'm pretty sure we're doing. some just some last-minute things, but mostly everything is good to go. So expect it pretty soon.

@0xSTVG: So does that mean that I could create multiple projects with subdomains of my ENS?

@peri: You could. But you can't have multiple projects using the same ENS name. So if you had like STVG.eth, and you want to do like one project one.STVG.eth and the other project two.STVG.eth, those could be two separate handles for different projects.

@mieos: Once we get that up and running, I think a screen recording of you going through that or WAGMI can put together a little infographic on what it is and how it works, especially when it gets up to the subdomain part, it's just technical enough.

veBanny by @Jmill​

I want to show a map with the veBanny stuff. I've been doing some work on the subgraph implementation to index the user tokens and interact with them. Right now we had a couple of big steps forward. One thing is there's now a metadata file to parse for all the the characters or the variants so you can go through and scroll through the characters and figure out which one you want and then you can see them all in here, too. So that's been a nice upgrade because you can pull that all from one place now.

(screen sharing ongoing)

So these are NFT positions that I've taken on this account. So you like lock positions that are actually coming from on chain. And then you can interact with them also, so I can do that to extend the lock or I can unlock the ones that have finished. So I can take this one and extend the lock like a thousand days. Then it takes a minute for the graph to re-index it, but it'll show up 30 seconds later with the new lockdate.

And then other than that I showed this last week, we have a new contract where you can mint for one second just like test the unlock and redeem stuff. But yeah, I showed this on the last demo where you can also like take a staking position and actually mint these things through the front end works also.

quizz time:​

The answer is....

Nicholas

• As a student I made jewelry and garment.
• I was a nationally ranked debater.
• I haven't been Malta before.

NFT update by @JohnnyD​

@JohnnyD: I'll just add a few sentences to what @aeolian has summarized before. We're gonna be automatically rewarding contributors NFTs when they contribute above a certain amount. and then the next step will be adding a restriction around, such as time restrictions so ensuring that those NFTs are distributed only before a certain funding cycle. But for now, we're just going with the amounts.

Announcement from @briley​

@briley: Yeah, thanks. I was just gonna make a small announcement that Matthew and I are recording podcast episode with lexicon Devils on Thursday if you have any questions that you would like to ask you can let us know. Otherwise, we'll be doing that in advance of the JB MorganStern's voxel slash IRL event.

Warning of Influx of new members.​

filipv: On June 7^th, the Discord server of JuiceboxDAO was faced with a big influx of new members from Indonesia. According to @Zeugh, they came from several big Telegram chat groups that are mainly focused on airdrops. There might be a misintrepretation that if they create a project on rinkeby.juicebox.money and give feedback in the Discord server, they will be entitiled to some kind of Juicebox airdrop. We don't have any airdrop currently.

Zeugh： I think it won't do any substantial harm to JuiceboxDAO, and think it a great opportunity to showcase the functionalities of our protocol to these people, and to onboard some new members who are really interested in our products.

veBanny Front End updates by @Jmill​

Jmill: I have been working pretty extensively on the veBanny front end, trying to get it out the door. Now that the contracts are deployed, we can work to transactions and use real data.

(sharing screen and demonstrating the process of staking tokens for an Locked NFT)

So we're now minting this thing through the website which is cool. The stuff is all working now, and show up pretty cool.

jango: I've also been on the contract side of things that @Viraz has been doing a great job, asking for reviews over the tests. The tests he's writing and adding more fuzzing tests to the suite. So hopefully at this point, it's throwing a lot of use cases at the cocept. And i suppose it'll make way on to the actual final details to complete the workflow.

Jmill: The big thing next is to read the onchain data and get the use of NFT, and then allow them to extend their locked positions on a particular NFT. All of those are related to fetching data, about multiple tokens. We're talking about this in Peel's Discord, and right now it's implemented as ERC-721 Enumerable, but it'll probably be easier if it were structured similiar with Juicebox projects where you have a directory structure and subgraph, to look that information up without recursive calls to open by index. So that's probably what we need to start thinking about how we index these information for the purpose of front end to grab it and work with the data.

jango: Yeah, that makes sense. Also from a juiceboxDAO or Juicebox perspective in Juicebox.money, we'll possibly first have to deploy their staking contract and specify the lock duration they want etc. It isn't going to be there for everyone first, they have to specify those things, so that that initial transaction to deploy a staking contract will go through a contract that somewhat serve as a directory or at least it'll file an event that's indexable to service a directory. If Peel and Juicebox.money feel it a decent thing to offer all projects over time and they should be able to interact with that same depolyer contract to get their own version of this.

filipv:What's the timeline looking like? Is that somehting we can expect deploying in the next month?

jango: We need V1 > V2 migration to do it for JuiceboxDAO. We can deploy this for an arbitrary project though. We can launch a new project and just has it work there, so you can start minting stuff, just as normal treasury and lock it there, at which point there's not much difference between test and rinkeby as we currently are. But to get the JuiceboxDAO version of this and the Bannyverse version at least from a ecosystem perspective, we need to get V1 > V2 migration, and then there might be other technical things along the way.

Jmill: From a front end perspective, there are a couple of things that would be helpful so that there's some kind of indexing data you can easily pull user's NFT statistics. That's a more simple and scalable way to do with subgraph query. It would be really usefull if the ve NFT contract deployer also deploy a single consolidated metadata file. Let's say veBanny has 60 characters and they all have a name and staking ranges, it'll be really nice that the contract generate that as one file that front end could grab and parse to display without going to 60 metadata files individually. That would be a quality-of-life thing from the contract side for the front end.

tankbottoms: We could add another function for that metadata, basically something that will conform with an NFT but also has pointers to all assets you need, because you can pick them through the JSONs however you want.

Jmill: The last item I have here is that we're implementing beneficiary for this, so that users can stake and put someone else as the beneficiary.

jango: That'll be useful for even a DAO to lock its supply, and designate other contributor or some other beneficiary for. It's cool to have flexibility. The core thing being built allows everyone on the peripheral of the project to start to wrap their heads around what situation it's gonna be when this thing is out there.

Product prospective with @Zeugh​

Zeugh: The Juicebox.money is a complex thing to use. I think it will be something to see that front end are more focused on some type of projects. Let's say there's a NFT project wants to launch its treasury on Juicebox, they can have a direct way for easy launch to help set it up ahead of time. You want to launch a NFT project and make the funds through Juicebox so people can co-own the treasury like tileDAO did and issue tokens for people that are minting.

Those are some of the configurations that we think we should do. That could be something like Juicebox.nft instead of Juicebox.money. And if you want to go to the hard mode and be able to configure every single thing, that's still running on the same protocol.

That's what I call the product prospective. We have a very good protocol perspective here that is building something really robust and can do lots of things. In the end looking at product level, maybe not all the users will need all of these things and having an easy way to launch might be something interesting.

jango: I think there's a lot of to keep improving the onboarding stuff and especially we just came out of V2 trying to start with parity where V1 was. The name of the game now is just constant improving based on our own interest with onboarding as well as pulling together other people's perspective. It's hard to be certain that it's one thing or another thing from my point of view, but without question we're going to hinge towards better alternatives to prototypes that are massively useful. Shout out to JohnnyD and Aeolian and all the people in Peel who are eager and quick to make prototypes and start discord threads so that we can discuss the improvements. And then match this with a occasional AHA moment that a few different ideas come together that make sense to a lot of folks and somehow we unlock a lot more fluidity to the onboarding process.

I'm certainly with you that we have a lot of work to do with explaining what people are getting into, like starting with giving everyone all the information upfront and make all risks as clear as possible. Overtime we can start to reel back into some managable shortcuts.

I think now we're definitely buckling for more long term investments both from a building perspective and the relationship perspective with other communities. I'm eager to see how that project chart changes over time. I think from my personal perspective and talking to projects, the recent lows haven't been very encouraging for projects to launch. But now that V2 is out, we're going to see a lot more of that.

nicholas: When I did onboarding with Austin from BuildGuild and he had some feedback about simplifying. It's a little bit difficult for someone on the outside to know exactly which simplifying approach will be successfull on the market aside from just iterating on simplifying the existing one. But I do have some suspicion that there are a larger category of people who are not so inclined to use Juicebox in its current form but might be inclined to do so for this example we're talking couple of times about NFT collections, splitting off a portion of their primary and/or secondary to Juicebox and letting the holders manage it, which doodles, cryptopunks and a bunch of other projects already do. That's a category I'm super interested in getting on the creation flow for that. It could be just like presets on what we've already got, or maybe an entirely separate creation flow where you can imagine entirely different front ends that just make creation really tight for a specific use case and then you can go use Juicebox.money's full advanced front end and subsequently managing those things but make it easier for people to get onboard. It could be pretty integrated at Juicebox.money. There's a lot to explore.

filipv: One thng that we've discussed that might be interesting would be if there's a way to easily import and export project configurations which Austin Griffith originally brought up, for exporting a project that was made on testnet to mainnet. That might be cool because you can use that feature to set up templates that have base project configurations.

Another thing I want to talk about is what we're discussing a lot in the chat about amount of metrics. I'm not sure how useful focusing on any specific North Star metric would be. It's very hard to encapsulate everything in Juicebox, and I think everything is conflating with each other. So I think we can take anything and roll with it, but I don't know if it's worthy going super deep into which is the best North Star metric.

Aeolian: I'm totally with @filipv. I think the goal I originally had with proposing this metric was not so much like "ok! Let's review this number every week!" or "Oh! it's going down, what's happening?" It's more like what we're all in some sense collectively optimizing for everything from a product, website, documentation and content strategy, the whole thing. Our goal right now is to increase the number of active projects. I agree with you that at this stage where traffic is still very low, really trying to hatch out a metric that's instructive right now. It's more to get us all on the same page.

jango: I think the general consensus is that it feels good to have activity. I guess you could put on a chart and optimize for it, but personally I want to think about metrics that make me lean in more in moment's notice seeing activities, and seeing folks I know engaging with other projects making me want to learn more about them.

Govenance discussion​

@filipv: I want to open up some discussion on the recent governance cycle, both in itself and some of the proposals.

One thing I want to bring up first is the possibility of changing the governance cycle in order to allow for longer temperature checks because I definitely feel the temp check are too short. But there's also balance if you lengthen the temp check, it makes it harder to get things through the governance process and it takes longer to get things done. We did a poll and people are really into the weekday idea.

nicholas: Since people prefer temp check ends during the week, I'd particularly like the proposal edit freeze to happen during the week, because I had to spend a lot of Sundays modifying proposals because people obviously just give comments leading up to the freeze and I prefer it end in the week. I understand people have jobs and I am certain that might not be convenient, but people from the poll seem to be happy with that idea.

jango: For me personally, it's nice to end on weekend because I can do a lot more meeting oriented and dev oriented stuff during the week, and in the weekend, I can read the proposals and think about those. There's not much weekend breaktime.

nicholas: How specified should proposals be? I made a suggestion that is three points if you add them to the proposals, maybe they will enable more delegation, because a lot of the burden getting the proposal through can be like knowing exactly what steps should be taken, when it's not always necessary DAO knows every single steps if DAO is willing to accept the risks, the implementation risk of someone delegating it to the person who's the author or someone specified in the proposal. I think it's a decent choice if it's a better financial allocation and also adding a risk in risk section which is like "Look, we're not specifying the address the money got set to, we don't think that's a super important detail for the DAO to be voting on", but that's a risk we can screw up sending it to a wrong address because it wasn't specified in the proposal. It allow the proposal to move forward before all those details are sorted out. Some proposal do deserve to have hyper detailed specifications and it's important for the DAO to vote on it, others delegation will be more appropriate. I think that might be a interesting format for making governance more manageable.

filipv: I'm definitely onboard with that. I think that thing need to be weighted very carefully just because it's not like we are going through a hierachy and people are revising it in every step. It's kind of like every proposal goest to the multisig like the one source of truth. It's like something running close to the middel very powerful and very dangerous. I think we need to be careful about specifications and and we don't want to lead to some DAO crisis when people are disagreeing on an interpretation of the proposal after the fact.

First of all it waste a bunch of time, also people are gonna get upset and may lead to conflicts. So I am generally more of a stickler that we should have very specific proposals just because how dangerous it is. I wonder if there is a way to incentivize people to submit a bunch of proposals earlier so they can be spread out ever a greater period of time. We really see most proposal submitted close to the end of temp check. It's not an easy question to solve.

nicholas: Part of the challenge is the 14days cycle, if you would like to submit a proposal for something and temp check submission just opened, that means you can no longer submit a proposal and you could be waiting for 20+ days till the next opportunity to vote. It may be worthwhile, for instance the bug bounty, I can see both sides on it, maybe a longer process allow us to consider, but at the same time, the protocol needs the bounty pretty badly.

I think it would be of some value not entirely in the direction of everything being specified because the reality is that just making through all of that governance and having opinions on it is stretching the limits of the bandwidth of even the most dedicated members of the DAO. It also becomes less decentralized the more because people are just voting along with other people who have already voted. There's also some needs to us to recognize that actually the DAO doesn't need to vote on every single details of everything, and some amount of delegation is probably gonna be necessary over the medium term.

filipv: Two thoughts on that.

One is that I don't see why we couldn't do it right now like approving a budget in advance to reduce future governance overhead and go through that process. I think that's very achievable and I'm interested in pursuing that.

Second thought is that jango has be mentioning lately the idea of possibly pursuing funding for projects and budgets for projects rather that fuding budgets for individuals or groups, which I think compelling because the structure of what we are doing shifts a lot and it's the post V2 transitory period. So I wonder maybe a shift towards budgeting for things get done rather than having all these smaller individual small group proposals may accomplish what you are talking about being able to improve things in advance and delegates to someone who's leading the project.

jango: Some of the treasury allocations have also been tricky in the past weeks because we've been tuning the treasury create stuff on and off while we address some protocol problem. Those should be made well in advance in proposals being specified to be directed towards them. I am definitely in the camp of more hyper specificity upfront and throughout the temp check process.

filipv: Would you want to work with Juicebox if you didn't get funding through an individual basis, but rather as a part of multiple projects?

jango: The end of payment routing is still individual payout, either from a project that you control like what JohnnyD has, or through a direct payment from a project. The idea is that it's just not managed by a conglomerate governance system.

felixander: I want to talk with JohnnyD and Aeolian about this. What happens when you bring a human on for a projects and the project is solved? It doesn't make sense for the system now because we've committed a budget to something that only took 2-3 months, but now somebody is there, but they're taking on another work that might be totally separating them from what they're doing. I think it's something a little bit messy in terms of how the payment structure works presently.

jango: I feel that kind of work is really important when a project is starting out, that's still the case now and will likely still be months into the future. There's a lot happening and everyone is contributing to whatever the next person needs. So people are just shouting "hey I got this dope thing in progress, it'd be sweet if I could have this ounce of help" and luckily there's a lot of people around who are eager and feeling supportive to do that work. So the individual payouts feel appropriate in that world.

I think that would set the expectation that there's a lot of stuff that we've building isn't just onging forever, we're not hired by JuiceboxDAO to be here comfortably and feel valued imbued and viewed by our relationship to one another and to the concept of the projects. Once those projects play themselves out, I think it's healthy to reassess what our purpose is amongst current state of the projects and how we can prepare ourselves for future state of uncertainty which are always upon us. That's the thing we can almost guarantee.

felixander: Would that be the same way like Peel, WAGMI and Canu, the idea that people would branch off like Peel now is under a budget to do front end? You could imagine people who are doing docs would branch out and have a budget, and people who are doing translation would also branch off and have a budget.

jango: I think that's in a creative part and I'm sure everyone will bring their own taste of how to frame these things. It's effective to pay Peel to work on the Juicebox.money project, front end developers can assess each other's contributions and payouts better than any multidisciplinary group would.

These things will inevitably shift and change over time, as people come and go, as well as the projects changing. It's tougher for the community to rationalize consistent budgeting for an abtract group of people with an abtract but pointed mission, the individuals are liquid between all these project organizaitons and we hve to respect that. People are going to find their leverage over time and they don't owe anything to any organizations. We're all just building ourselves out and learning from each other in this whole process. I think we're going to see a lot of different ways to organize it.

Shout out to Zom_Bae creating the Juicebox events version for the upcoming ice cream event and it's in a potential to add more longevity to that concept. What if we're to actually trying to fund events consistently and have a pool of resources that we can make this up every single time. We can just re-reference something that we know to be true already.

I think we're on the same page eventually. We've got to create the right incentive model to shift away from building up the Juicebox foundation to supporting one in any numbers of projects and then servie it to the world and make it the gateway. But as the protocol tends towards stability, it'll be great to have tighter articulation of what it means for a project to succeed over time.

Aeolian: I do like what @casstoshi brought up about the idea of each group having a budget and individual contributors are paid from that budget. I think Peel has done this. At a time all the front end people were doing individual proposals to JuiceboxDAO and the sentiment was that it's hard to evaluate these proposals. So intead JuiceboxDAO votes on a single budget for front end and that team can handle that budget as they see fit.

I'll post a link that Drgorilla posted earlier about how makerDAO manages this process where there's a clear budget for each abstract collecton of people. It definitely breaks down as we've seen with some proposals over the last couple of weeks. It's hard to pinpoint someone into one of those particular groups, people can work ver much across thses groups.

I still think it's instrutive not only from accounting perspective but also from an organizational perspective, it just makes it easy to reason about someone's payout if they're clearly contributing to a specific area.

Project highlights​

gogo: I'm very glad to be able to discover the future of ComicsDAO and strategy of what we're gonna do there. We had a super contribution from JuiceboxDAO from the beginning which is pretty amazing.

I would like to share what we just thought. So we basically are doing a full story and the beginning starts with this post here. What I would like to propose is that this is our heroes Banny and they're travelling throught the DAO galaxy to DAOs. We would like to know where JuiceboxDAO would like the ship to go to the next DAO, so that we can keep on building covers to next DAO. Let's create a poll here and vote on the DAO that JuiceboxDAO decides what ComicsDAO is gonna do next.

Another thing is that, we had a big player, this guy is amazing and helps us a lot.

We are having fun creating next cover for other DAO, and we are going to make some jokes for JokeDAO and get partnership to work with them.

jango: That's the coolest part of ComicsDAO. I love the treasury management, a part of which is to buy rare comics and hold thme, but the day to day potential of being the storytelling branch of differnt DAOs, which is immensely powerful. And so far you are all playing really well, well done.

nicholas: There're a bunch of really cool projects this week. JokeDAO just launched a super sick governance experimentation project.

Austin Griffith's BuildGuild got launched this week and there's a proposal to fund a hackathon for them to transform scaffold-eth into something compatible with Juicebox or to build the hackathon projects using scaffold-eth with juicebox involved in the picture. And as jango mentioned in his twitter that Juicebox front end is based on scaffold-eth.

So it's very cool to see comfort circle, and hopefully we will be able to fund a modest hackathon to get the treasury kickstarted with funds, hopefully getting that brew of hackers into the ecosystem.

@twodam's has posted a twitter about this week's projects here.

jango: Super exciting. Thank you @nicholas for doing a lot. Most excited once we get the V1 V2 token stuff, situated to start talking to the SharkDAO, or a lot of folks operating on V1 still doing ongoing work and fundraising, to see if they want to move over and leverage some of the new tools to make their projects more successful, whatever that means to them these days. But I think we're still a little ways away, so getting new projects on is still the name of the game for sure.

Quizz time:​

Oh man, this episode definitely needs a PG rating for sure. I won't compile it so if you are interested, check out recording and jump in to 1h25'00", you're welcome!

And the answer is........

Sage