Nance Updates by Jigglyjams​

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

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

  

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

  

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

  

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

V4 Updates by Jango​

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

Proposal to integrate V4 on Juicebox.money​

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

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

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

Interfaces of Juicebox V4 protocol​

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

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

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

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

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

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

Bannyverse 部署脚本工作报告 —— Jango​

Jango 最近正在编写 Bannyverse 的部署脚本。Bannyverse 是一个表面层项目，这个项目把我们最近所做过的工作全都串了起来。听起来确实很酷，但同时也意味着它包含了非常多的组件，例如 721 钩子（标准 JBNFT），通过 revnet 和 Juicebox V4 协议附加的回购委托，还有一些其他 Croptop 元素，基本上都整合到这一个项目里面。

Jango 介绍，在 Banny 合约内，有一个组件是 Bannyverse 独有的，也就是 721TokenUriResolver，这个代币 URI 解析器把不同各类的 NFT 糅合在一起，使整个 Bannyverse 成为可能。它通过显示代币 URI、SVG 数据和裸体 Banny 的服装配件 ID，支持我们给自己拥有的 Banny NFT 穿戴服装配件，实现裸体 Banny 穿戴不同服饰的可视化效果。

在周会上，Jango 逐行解释了 Bannyverse 的部署脚本的具体内容，在分享最近一段时间团队工作成果的同时，也让其他社区成员尝试从程序员的角度来增加了解。这个部署脚本目前仍欠缺最后两个非常重要组件，跨链吸币器和兑换终端，等两个组件开发完成之后，很简单就能添加到这个脚本里面。

确定区块链​

由于 Bannyverse 基本上可以在任何区块链上进行部署，我们首先需要确定即将部署的具体某个区块链。

依赖代码库​

从依赖代码库调用的所有合约如下：

加载地址​

然后我们就会确定多终端、规则集、回购钩子、NFT 钩子、钩子商店以及 revnet Croptop 部署器等的合约地址。

顶层元数据​

我们还要定义包括 logo 及其他所有元数据在内的一些顶层数据，这些数据将会在类似 Juicebox.money 这样的前端网站上进行显示。

接收资金的代币​

我们将通过以下代码来设定项目将要接收资金的终端，它将被设定为接受当前区块链的原生代币。这里设定的是以太坊或其他区块链上的 ETH。

我们会在这个部分增加支持用其他代币接收资金的其他终端，即将完成的兑换终端也会出现在这里。

Revnet 阶段设置​

以下我们将配置 Bannyverse revnet 的不同阶段，它正式启动时将会预设好两个阶段。每个阶段都会配置各自的起始时间、操作员分配比例、初始发行比率、天花板价格和地板价税率，等等。

Revnet 配置​

在 revnet 的主要配置中加入阶段设置信息后，我们接下来会设定基础货币、预挖数量以及初始操作员。

回购钩子配置​

然后我们会对回购钩子进行配置，设定参数来决定实现回购的具体价格。我们还将定义流动性池及 TWAP （时间加权平均价格）等参数。

下面的部分，我们对回购钩子的配置进行引用，并同时明确回购钩子的合约地址。

NFT 等级​

这里我们将预加载 4 个不同稀有程度的裸体 Banny NFT，它们的价格不同，发行量也不一样。

Croptop 参数​

以下这些参数用于允许人们把自己的服饰配件发布到项目的 NFT 系列。项目方不再是唯一有权在 Bannyverse 发布新物品的人，最终 Bannyverse 将发展成为一个每个人都能够发布收藏品的世界。

广播上链​

至此，我们已经设置好所有的细节，接着就要把项目广播到链上。我们会发送两个交易。第一个交易是部署 URI 解析器，也就是专用的 Banny 解析器合约。第二个交易则是通过 deployCroptopRevnetFor() 函数来部署 revnet, 函数会正式启动这个项目，并把诸如名称、符号、项目 URI、revnet 配置、终端配置、回购钩子配置、NFT 钩子配置及 Croptop 发布等 Croptop 相关的参数传递进去。

运行这个脚本之后，一个销售裸体 Banny 的 Bannyverse revnet 应该就创建成功了，除了使用正常的 Juicebox 协议组件，将来还会增加 Banny 服饰的支持。

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

接下来的 Bananapus 项目我们也会使用类似的部署脚本，Bananapus 是协议的收费项目，但项目内不会包含 NFT 或 Croptop 等功能。

Bannyverse 背景介绍 —— Jango​

从视觉角度来看，Bannyverse 重生于我们制作于一年半前一整套非常丰富的 Banny 材料。

原本这些材料计划用于一个更着重于治理用途的项目，这个项目允许 JBX 持有人质押他们的代币来相应获得 veBanny NFT，再按他们锁定 JBX 的时间长度及数量来决定这些 veBanny NFT 的治理投票权重。由于种种原因，项目一直没能实现产品化。

在这一期间，JuiceboxDAO 一直在致力于解决一些确保协议稳健的先决条件，例如协议版本控制、安全相关工作、风险控制工作以及最近的 Revnet 开发，正是因为这些工作优先级更高的原因，Banny 项目一直被搁置至今。

Jango、Mieos 和 Lurmoth 等人最近经过讨论后决定，重启 Bannyverse 项目及将其应用当前环境的时机已经成熟。他们开始构想，如何让 Banny 不仅 Web3 NFT 的形式，反而更多作为生态系统的相关角色，来展示在屏幕上讲述 Juicebox 的故事。当前的工作主要围绕如何能够把各种因素整合到一起，在过去的几个周期，这些想法通过提案的形式提交到 JuiceboxDAO 一起展开了讨论并得到改善。

最初，Bannyverse 将会作为人们在以太坊主网和 Optimism 上铸造裸体 Banny 一系列 NFT 的展示窗口，以后我们将会进一步扩展到更多的其他区块链。

四个等级不同稀有度的裸体 Banny 将作为基础角色，而 Mieos 将会主导将来制作、展示各种各样 Banny 服饰的工作，让持有裸体 Banny NFT 的人可以购买服饰配件并按自己的喜好来装扮自己的 Banny。同时 Lurkmoth 还会制作一些动画短片来配合这些 NFT 系列的销售，共同来为 Bannyverse 的推广做宣传。

感谢 JuiceboxDAO 一直以来在这个工作上的支持，Bannyverse 有望成为我们很好的起点，但同时我们也希望开启一个良性循环，帮助把兴趣和注意力引导回 Juicebox 文化，并吸引更多的捐款人、新项目和新想法的出现。我们将坦诚面对未来的各种不确定性。

Juicebox V4 单元测试报告 —— Nowonder​

Nowonder 最近致力于 Juicebox V4 协议的单元测试工作，以尽可能小的方式来覆盖每个合约的所有逻辑分支，基本上等于部署一个单一合约来对其他合约进行其他调用，模拟这些调用并返回数据，确保所有工作逻辑都运行无误。鉴于 Juicebox V3 协议已经是一个非常全面的软件，他预计测试最多能找到一些少量的优化结果。但他也表示，如果将来协议的实现发生变化，单元测试将有助于准确发现变化的内容，并能确定这些变更都是安全无害的。

Jango 对此深表感谢，他表示这方面的工作正是我们可以进行更高层次艺术抽象的原因所在，因为我们背后有一大群贡献者，他们做了许许多多不为人所知的工作。

Nouns 493 号提案报告 —— Matthew​

Nouns 493 号提案，建议向 Free Alexey & Roman project 项目捐款 40 ETH 支持两位 Tornado Cash 开发者的法律辩护工作，这项提案已经高票获得 Nouns 社区的通过。这是 Nouns 社区首次通过提案形式直接从 Nouns DAO 金库向某一个 Juicebox 项目进行捐款。

很不幸运，由于 Nouns 治理前端的一个错误，执行这项提案的交易失败了。尽管问题已经进行了修复，提案仍然需要重新提交到社区再次接受投票。Matthew 表示，他并不太担心需要重新走一次同样的治理流程，因为上次投票结果显示这个提案赢得了大多数人的支持。

Matthew 和 Brileigh 认为他们可以设法说服其他 DAO 来支持一个好的 Juicebox 项目，并表示这项工作的重点在于与借助合适的人帮助以及与目标社区的有效沟通。他们计划将面向一些更大型类似 Arbitrum 及 Optimism 等 DAO 组织实施这一战略，希望能够成功找到更多 DAO 金库来与 Juicebox 协议进行交互。

部署计划工作报告 —— Jango​

Bannyverse​

目前 Bannyverse 的 revnet 部署仍需要的东西包括媒体内容、裸体 Banny、Banny 服装配件、宣传资料，以及在外部联系、社交媒体和市场推广方面的一些工作。

Bannyverse 部署的时间安排如下：

• 目标测试网产品化备选将于 2 月 12 日左右在以太主网、Optimism 甚至 Arbitrum 上进行部署；
• 产品化部署将于 2 月 17 - 20 日进行。

这次的产品发布包含很多先决条件及其他因素，所以需要在许多参与开发人员和许多微妙的基础设施之间进行协调。按以上的时间规划，团队还有三个星期来实际推进产品化的工作，把所有的东西部署到测试网上，尽可能地测试和查漏补缺，最后再正式拉开这个专项试验的序幕。

把 Bannyverse 作为第一个项目来进行部署，是出于 Banny 可能比我们任何人都更适合解释 Revnet 和 Bananapus 工作原理的考虑。通过各种 Banny 的 NFT 和其文化渗透，艺术创作的参与以及屏幕上几个简单的按钮，我们就可以把所有强大的工具传递给新用户，这些工具可以扩展用于解决生态系统内任意的其他问题。

目前团队仍在致力于开发一些与 Bannyverse 交互体验相关的早期原型化产品。

Revnet​

Aeolian 正在开发 Revnet 的网站 revnet.app。应该还有一些框架搭建工作需要进一步完善。

从用户体验的角度来看，我们需要在支持 revnet 设置不同的阶段，这也是 Bannyverse 最后进入产品化的唯一一个影响因素。

类似 Bannyverse 这样的 revnet 将在各自网站上展开自己不同的叙事，但如果人们对这些 revnet 的经济模型更感兴趣，或者 $BANNY 或其他代币的持有人希望获得自己网络金库中的收入，他们可以跳转回来 revnet.app 上对应的项目页面进行操作。

Bananapus​

从 Bananapus 的角度来看，我们需要在协议将要部署的地方，如以太主网、Optimism 或者 Arbitrum 等，创建收取费用的一号项目。在展开经营活动之前，我们需要设置好金库来收取协议使用的费用。

Dr.Gorilla 开发了一个兑换终端产品，让项目可以允许任何人使用任意代币进行支付，然后兑换成项目用于结算的代币。鉴于 Bananapus 将于多个不同的区块链进行部署，它需要配置这个兑换终端，因为人们究竟会用什么代币来支付费用很难提前确定。用于支付费用的代币并不一定总是 ETH，可能是不同区块链自己的原生代币。因此，我们希望确定 Bananapus 作为收取费用的主项目，可以配置好兑换终端并能够接受不同代币来支付费用。

另一个我们希望在 Bananapus 上配置的基础设施，是由 0xBA5ED 负责开发的跨链吸币器。项目可以在任意链上获得收入，然后收入及相应的代币发行将会被吸取到负责发行项目代币的主网络。很显然，这一设施对于进行 Banny 的多区块链销售，以及 Bananapus 多区块链收取费用并归集到 $NANA 代币都很必要。Bananapus 部署之后, JuiceboxDAO 在这个项目的权益敞口也主要集中在 $NANA 代币的持有上。

其他我们可以进一步推进但偏社会性多于技术性的事情，则是争取与其他部署目标区块链环境，例如 Optimism、Arbitrum、Base、Zora 等展开合作。我们可能会不请自来，他们可以在了解情况后，视自己的需要决定是否共同展开流量的引导。

我们将会在 Bananapus 上执行大量的测试工作。当我们把 Bananapus 精简至 revnet 的形式进行启动时，从避免攻击的角度来看，我们基本上会移除四分之三的 Bananapus 代码库。通过其中一个项目来启动，我们可以集中精力进行测试，从而确保代码同样在所有其他 revnet 上工作无误。

其他​

各项条件基本已经就绪，现在只等正式启动，确保一切工作良好及互相配合，并且清晰明白容易记录，等等。

Jango 在当前周期提交了一个提案建议 JuiceboxDAO 向即将启动的 Bannyverse revnet 支付 40 ETH 并获取项目的裸体 Banny NFT 和 $BANNY 代币。他同时在周会上表示，不管提案是否获得通过，由于 JuiceboxDAO 早期对 Banny 的投资及开发工作，它仍将通过品牌资产及获得预挖 $BANNY 代币分配的形式，在这个项目中实现利益关联。

Filipv 建议，我们应该配备人手来向不同的 L2 网络，如 Optimism 或 Arbitrum，编写申请资助提案来支持 Bananapus 和 Revnet 的发展，由于这些 L2 网络的申请流程各有不同，这项工作可能会非常耗时耗力。Jango 表示，我们早期应该集中精力在 Optimism 进行申请，因为我们计划会先在 Optimism 部署销售 Banny NFT。Matthew 及 Brileigh 都在编写资助提案方面有一定的经验，加上他们目前现在 Arbitrum 走提案流程争取为 Free Alexey & Roman 获得更多支持，他们表示愿意帮忙从事这方面的工作。

Nouns 提案工作报告 —— Matthew 及 Brileigh​

Matthew 及 Brileigh 成功在 Nouns 社区发起一项关于 Free Alexey & Roman 项目的提案，倡议 NounsDAO 向项目捐款 40 ETH，共同支持两位 Tornado Cash 开发者的法律辩护工作。

Matthew 呼吁在 Nouns 社区有人脉资源的成员帮忙为这个提案争取更多的支持。他表示，Nouns 社区如果能共同参与这个捍卫编写代码和隐私权利的斗争，将会是我们工作的一大胜利。同时他也很希望能看到 Nouns 第一次向某一个 Juicebox 项目捐款并与 Juicebox 协议进行交互。

在周会上，Matthew 还分享了一篇由 Nouns 社区一位叫 brennen.eth 的开发者撰写的投票意见。Matthew 表示对这篇文章极为赞赏，认为它清晰表达了当前这个筹款运动的一些想法，同时也反映了大家对我们为支持两位 Tornado Cash 开发者所做工作的深切认同。

V4 术语变更工作报告 -- Jango​

Bananapus 对 Juicebox V3 协议的分叉已经正式清理完毕，最后还剩下一个术语变更的拉取请求。这个拉取请求共涵盖 95 个文件的名称更改，但不会涉及任何合约实现上的变更。

这个工作主要归功于 Filipv 过去几个月以来的辛勤工作，所有变更都在之前的周会及相关的讨论组里进行了集体审核。

本次周会上面，Jango 着重介绍了这个拉取请求所包含的部分比较重要的变化，同时指出，协议在测试网部署之后，下面几个星期会有越来越多人开始尝试对 V4 协议的整合，因此我们将会经常接触到这些合约变更之后的名称。

Rulesets 规则集​

筹款周期现在改称为规则集，这样我们可以用项目当前的规则集和后面排队等待生效的规则集来对项目来进行表述。

目前 V4 协议支持同时排队交易多个项目规则配置的设定，项目方可以一次性排队多个不同的规则集，例如，他们可以部署项目，并提供清晰的指引，告知社区成员之后一年内项目的规则将如何发生不同的变化。Jango 很期望能看到人们使用这个灵活的功能来展开各种各样的建设工作。

Tokens and credits 代币及点数​

我们之前用未领取代币（协议内部追踪统计的代币）和已领取代币（由持有人自行保管的 ERC-20 标准代币）区别代币不同的状态，现在改用点数及代币来分别表述这两个不同的状态。

默认情况下，项目收到付款时，会向付款人分配相应的点数。如果项目方日后选择签发 ERC-20 标准代币或者引入已发行代币，这些点数就可以用来领取成相应数量的代币。

Decay rate 衰减率​

我们现在用衰减率取代折扣率来描述项目代币发行减少的速度。

JBPermissions​

我们把 JBOperator 改称为 JBPermission，通过这个合约，项目方可以委托其他地址来代为管理不同的合约。合约同时还引入了一个根权限，允许项目方授权其他人代为执行全部操作，甚至包括向其他操作员的授权行为。

Bananapus 实施计划 -- Jango​

随着合约重命名的拉取请求即将合并，Jango 计划在以太坊的 Sepolia 测试网及 Optimism 测试网上执行 V4 协议的部署，实现协议 L1 和 L2 区块链的同时部署。

Jango 计划每周日晚上把上一周所有大家讨论并通过的变更收集起来，必要的时候甚至可以重新进行合约部署，这样我们新的一周基本都可以把上周的问题清理干净，并继续在最新版本进行迭代。

每周我们都会创建一些新的拉取请求，类似命名调整、小规模的合约实现或者其他计划中的优化工作等，慢慢把它们合并到合约里面。我们将会在测试网上扮演培育者的角色，并通过编写清晰的每周变更日志来把曾经做过的改进记录交待清楚。

我们还会继续执行大量的测试来确保合约尽可能完善，同时争取提供高质量的相关技术文档。

我们每周还将增加一个过去几个月开发的一些新功能，实现它们的产品化并整合到协议里面。新功能的整合会按 Jango 在讨论区分享的以下步调逐步进行。

兑换终端是一个支持项目接受任何虚拟货币付款的组件。接收到的虚拟货币将会自动兑换成项目的金库资产货币，对需要通过多种代币来收取费用的项目来说非常有用。

Sucker 合约支持项目之间的跨链代币转账，使用信使进行沟通并通过赎回机制来实现代币的交换。

Revnet 测试研讨会 -- Jango​

有很多人希望以 revnet 的形式来运营他们的项目，而且我们也正在筹备第一批 revnet 项目的创建，Jango 计划举办一些 revnet 的测试研讨会，让大家一起来探讨怎样配置一个 revnet 并对其加以测试，这对协议来说是一个双赢的局面，有助于改进合约术语命名及全面改善 V4 协议的功能。

到明年 1 月中或月底，我们希望能够推出一个产品化模型，供各个筹备中的 revnet 项目如 NANA、Revnet、Defifa、Croptop 或 Juicecrowd 等用于各自项目的测试和试验。

项目发展报告 -- Filipv​

Filipv 介绍，CryoDAO 项目正在做一些很令人兴奋的事情，他鼓励我们的社区成员加入他们的 Discord 服务并更多地参与到这个项目里去。

Roman Storm 项目计划于下周启动。Artizen 的 Rene 也计划在同一期间发表项目启动文案及为 Artizen 项目展开宣传。

电报群 -- Jango​

Jango 介绍，我们目前创建了一个电报群用于代币交易等方面的讨论。Jango 说，他最近已经不再在 JuiceboxDAO 领取定期报酬，接下来的一段时间里，他很乐意更多地参与到 JBX 的叙事和教育方面的工作。

他认为，大家提出了一些很好的问题，我们应该正面面对这些问题、诚实回应并提醒存在的风险，同时也可以让大家更多地了解我们之前努力开发的产品，它们所拥有的机会。我们大家都应该认识到 JBX 的真正价值所在。

Juicecrowd 工作报告 -- Matthew​

Juicecrowd 去中心应用已经部署并运行了几个星期。Juicecrowd 团队，包括 Matthew、Brileigh、TJL 和其他 Peel 成员，启动了一个 Juicecrowd 计划，协助具有 Web3 或区块链愿景的项目来组织他们的筹款活动，加强能见度及促进社区的发展。

截至目前，Juicecrowd 计划的第一批项目全部成功创建并已经部署到区块链上进行运营。

Juicecrowd 团队还为早期的项目支持者提供了一些激励措施，包括获得由 Sage 和 Strath 制作的独家纪念 NFT 的空投，以及参与抽奖赢取 25万个 JBX 的资格。获得早期支持者资格的截止日期已延长至 2023 年 11 月 08 日，确保更多人有机会参与活动并向 JC01 项目捐款。

Matthew 呼吁社区成员帮助传播这些项目并进行宣传。他同时介绍，团队将与这些项目密切合作，争取扩大它们的影响力，从而获得更多支持，甚至可以包括申请其他平台资助等。

Filipv 认为，这批项目里面有很多感觉发展潜力巨大，他很希望能看到这些项目在这个计划帮助之下获得动力并实现自己的发展。

Bananapus 分叉工作 -- Jango​

所有待合并及将在测试网进行部署的 Bananapus 变更内容都已经整合到项目的 GitHub存储库。

目前仍有两个拉取请求（PR）最后等待合并。其中一个是 Filipv 已经着手进行一段时间的合约术语调整，这些更改之前也在我们的周会上进行了审议讨论。

另一个拉取请求则是要在支付终端上启用元交易，从而允许客户在选择中继节点时更加灵活。通过元交易，最终用户可以签署一条消息来表明意图，并将消息传递给中继节点，中继节点则代表用户提交交易并代为支付执行交易所需的 gas 费用，同时在合约层面上保持交易消息发送方的记录准确一致。

随着这个工作在接下来的几天内完成合并，Jango 期望可以在本周末实现这个 Juicebox 协议的 V4 分叉在Optimism 及以太坊测试网的部署。之后，我们将可以把它用作 Revnet 合约、Defifa 合约、721Delegate 合约，以及 Croptop 合约等的核心协议依赖。所有这些应用随后也将会在测试网上启动并进行最终的测试。

然后团队将在 12 月展开全面的测试，同时会着眼于 revnet.app 和 defifa.net 等客户端的开发工作，争取把它们全部集成到各自的测试网部署，以便进行测试并发现可能存在的错误。

另外还有一点值得关注，据 Jango 介绍，团队对支付终端架构进行了重构，争取将来实现单个支付终端的多代币管理。Bananapus 分叉将以实现多终端及多代币支持为目标，来满足项目和其他跨链组织的需求。

Token Table Revnet 开发工作报告 -- LJ​

TokenTable 团队之前关于资助 JuiceTable（TokenTable）团队与 RevNet 核心团队进行共同开发 的提案已经获得 DAO 批准，他们将会开发专为 Revnet 上的项目创建者和捐款人定制的代币解锁合约和 Telegram 机器人，产品预计将分成三个阶段进行交付，DAO 的拨款也会同步进行支付。

LJ 报告说，他们第一阶段的工作取得了显著的进展，创建了 Telegram 机器人的 Figma 线框图，并在开发中听取了社区的反馈意见。他们计划近期将发表更多关于 Revnet 的一些想法。

Nance 工作报告 -- Jigglyjams​

Nance 团队正在开发一个新的创建流程，预计将在下周初完成。如果有新项目希望创建他们的 Nance 自动化治理页面，可以与团队取得联系。我们希望能有一些真实的用户积极参与并帮助测试这个产品。

Banny Warhol 工作报告​

Jango 介绍，JuiceboxDAO Discord 服务器的 Banny Warhol 频道实现了重大更新。用户可以与频道的 Banny Warhol 机器人进行互动，通过提供简单的提示语或问题，生成一些 Banny 相关的图像或者咨询 Juicebox 协议相关的一些信息。

Jmill、Genekogan 和其他 Eden 团队成员计划将他们的生成艺术服务转变成一个能够为用户打造主题角色的平台。他们将以 Banny 为原型来开展这个创新性转变的尝试。

Jmill 在讨论中的发言更好地诠释他们这个工作的愿景，“我们正在向着自助生成角色系统的方向发展，争取能够开发出可以按用户需求风格实现对话、答疑及创建图像的主题角色。”

Jango 认为这是一个具有很大潜力的工具。除了在制作图像、项目标志或生成娱乐性的内容方面的应用之外，它还可以帮助塑造和扩展类似我们 Bannyverse 这样的具体角色的衍生概念。

Filipv 表示，Stable Diffusion 最近推出了一个新的 SVD 模型，如果将来可以整合到 Banny Warhol 中，这个产品可能会实现一些非常好的效果。

MoonDAO 工作报告 -- Jango​

MoonDAO 大约两年前创建于 Juicebox 协议。筹款活动成功之后，他们购买了两张 Blue Origin 太空飞船的机票。在 2022 年 8 月，他们成功地将一名成员送上 Blue Origin 飞船进入外太空，这是一个 DAO 首次实现的壮举。

去年，MoonDAO 还举办了一场抽奖活动，从免费铸造的 “Ticket to Space” NFT 随机抽取一名社区成员，活动的幸运儿是来自中国的 MoonDAO 社区成员 Yan，他赢得了第二张太空之旅的机票。但是尽管 MoonDAO 多次努力帮助，由于种种原因，Yan 一直未能成功获得前往美国的签证。最终，社区决定重新抽奖，选出另一位社区成员进行这次外太空之旅。

MoonDAO 同时正在进行许多项目，并与 NASA 等机构保持着紧密的关系。MoonDAO 的创始人之一 Pablo 始终致力于完成社区的使命，希望实现进入太空并在月球上建立一个基地的野心计划。与此同时，Pablo 一直密切关注 JuiceboxDAO 最近的工作，并分享一些建议。Jango 在周会上表示对 MoonDAO 及 Pablo 为追求目标而持之以恒的努力表示敬佩。

Juicecrowd 工作报告 -- Matthew​

Juicecrowd 的 JC01 计划截止本次周会时已收到了 35-36 个项目的申请。Matthew 呼吁社区成员帮助宣传，并推荐一些他们了解的项目申请参与这个计划。

Peel 和 JuiceboxDAO 的贡献者将会对这些项目进行投票，以帮助选择哪些项目将符合 JC01 计划的资格。Juicecrowd 团队将与第一批选中的项目展开合作，而这些项目将于 11 月 17 日启动他们的 Juicecrowd 项目。

下周，团队计划每天举办一到两个小时的研讨会，邀请第一批项目的团队分享他们打算如何制定策略开展筹款活动、启动项目、推广及提高可见度。Tjl、Brileigh、Matthew 及一些其他贡献者，将在此期间通过某种课程形式分享一些关于众筹的知识。

所有项目启动后将会运行到 12 月 15 日，围绕筹款的成果展开竞争，最后产生的前 3 名项目将从 3 ETH 的奖金池中获得奖励。

Bananapus 及 Revnet 工作报告 -- Jango​

短期路线图是要在本月底之前在主网和 Optimism 上实现测试网部署，今年内先在测试网上运行，与此同时，团队将继续编写大量的测试和技术文档，确保一切准备就绪，并将这些部署用于生产环境的测试。

以下是下周预计要完成的工作，这些工作将确保我们在月底前完成一个稳定的测试网部署，用于进行 Bananapus 试验的 Revnet 运营。那样我们就可以为任何有兴趣把项目构建成 Revnet 的人运行测试网实现。

Jango表示，团队原本计划针对 V4 协议（Juicebox V3协议的一个专门用途的分叉）的合约举行一次 Code4rena 审计比赛，但由于 Code4rena 此次审计比赛的报价高达 80,000美元，我们感觉太昂贵不值得。因此，我们计划自行提供一些奖励，邀请我们熟悉的审计者或生态系统内希望提供帮助的人，来协助审核这个经过精心编写和测试的代码库，让这个项目尽可能更完善，以便在假期结束后将项目部署到主网。

Juicebox V4 命名工作报告 -- Filipv​

在 10 月 17 日的周会上，Filipv 分享了 V4 协议（Bananapus 项目对 Juicebox V3 协议的分叉）命名方案的工作报告。Filipv 在会上提供了一些命名的备选方案，并解释了重新命名的一些原因，然后在我们的 Discord 频道中进行一些简单的投票，让大家做出选择并留下自己的反馈。

上周，Jango 与 Filipv 逐一核对那次周会上大家的反馈，并按照这些意见进行了一些修改。在本次周会上，Filipv 展示了相关的修订版本，并进一步征求大家意见。

JBTokens​

当项目使用 JBTokens 合约的默认实现来部署可领取代币时，这些实现方法将在名称中添加上 ERC-20，如 deployERC-20TokenFor(...)，而其他实现则仅称之为 token，如 setTokenFor(...)，来进行区分。

我们现在的做法是，用未领取代币和已领取代币来区分内部映射的代币和正式的 ERC-20 代币，这个命名方式让很多人感到相当困惑。Jango 建议我们把未领取代币称为 "token credits（代币余额）"，这些余额可以随时领取为正式代币，而把那些正式的代币称为 "tokens（代币）" 来消除歧义。

JBRulesets​

大家似乎普遍支持将 Funding Cycle（筹款周期）改称为 Ruleset（规则集合），也就是在一段固定或无限的时间长度内生效的一组规则。例如，我们将把 JBFundingCycleStore 更改为 JBRulesetStore。

现在的折扣率，我们将改称为 “衰减率”，因为它所体现的是发行比率或发行权重的衰减。

JBPermissions​

这个合同目前的名称是 JBOperatorStore，它的作用是授权其他人代表项目方来管理项目或与协议进行交互，因此把它改称为 JBPermissions 意思更准确，但在各种方法的名称中，仍然会沿用 Operator（操作员）这个术语，例如 setPermissionsForOperator(...)，会比 setOperator(...) 更清晰一些。

JBController​

这个合约我们只是做了少量更改。例如，reservedTokenBalanceOf 会读取待分配的预留代币数量，因此把它重命名为 undistributedReserveTokenBalanceOf 听起来更加清晰。

Payout Limit​

把分配限额改成支出限额的想法似乎得到了大多数人的支持，它表达的是项目在一个周期内可以从终端支出的 ETH 或其他代币的最大金额。

Runway vs. Overflow​

这个变更在本次周会中仍然具有争议。

Jango 认为，overflow （溢出）是一个有趣的 Juicebox 特色用词，就像一个满溢的果汁杯一样，它传达的概念是，某样事物装满了之后就会满溢出来。但是，许多项目也将溢出解读为 “runway（跑道）”，刨开项目的定期支出或一些应付款项，剩下的就是项目的跑道。跑道这个叫法清晰传递了，除了项目按照配置需要使用的部分之外，社区捐款人一直可以获取社区剩余资源的概念。

Matthew 认为跑道往往会给人一种项目还可以存续多长时间的暗示，它并没有包含反映项目支出之外剩余资金的含义，而 overflow 则带有这层含义。

Filipv 认为 runway 更易于向第一次接触项目创建流程的人来进行传达，在满足他们支出需要之余，超出的部分全部都是项目的跑道。如果项目有很多多余的跑道，社区就可以用他们的代币来进行赎回。人们也往往把跑道视为将来可用于项目的资金量。

Terminals​

我们稍微缩短终端的名称，从IJBPaymentTerminal改为IJBTerminal，因为终端的基本实现仅为支持付款，不需要重复说明。

由于 V4 协议将在多个区块链上部署，因此许多 ETH 术语需要相应地进行更改，例如从JBETHPaymentTerminal更改为JBNativeTerminal，来反映目标区块链的原生代币。

与JBERC20PaymentTerminal相比，JBERC20Terminal表达更全面，因为通过这个终端还可以进行其他不同的操作，并不仅限于支付功能。

JBERC20Token​

目前这个合约叫 JBToken。

JBProjectPaymentForwarder​

这个合约目前称为 JBProjectPayer，用于收到的 ETH 付款转发到各个项目。我们认为在这种情况下使用“forwarder” 表达更准确。

Hooks​

我们在考虑怎样才能更清晰地表达数据源和委托的概念，这个概念经常让人感到困惑。从上次讨论中的投票结果来看，大家似乎觉得在不同的编程背景下，“hook （勾子）” 的意义更加符合要求。

数据源提前向支付函数提供数据的一个函数，而委托则是在支付函数或基本支付逻辑完成之后的实际行为。我们决定将它们分为提供数据的“pay data hook（支付数据勾子）”和执行操作的 “pay action hook（支付执行勾子）”。赎回数据勾子和赎回执行勾子等作相同的处理。

当前的 Ballot （选票合约）是批准新筹款周期之前检查各个条件是否符合的一个合约，用户也可以定义其他所需的任何行为。我们认为，把所有这些行为放到勾子的框架下面，可以清晰地传达人们可以轻松地编写自己的合约版本并对协议进行扩展的概念。因此，“Ballot” 改称为 “Ruleset approval hook（规则集审核勾子”，而 “ State”（描述批准或拒绝的状态）称为 “approval status（审核状态）” 表达更加准确。

Artizen 工作报告 -- Filipv​

大约有 75 个项目通过 Aritizen 的审核并符合 Juicebox 项目加速器的申请资格。

Filipv 认为我们在设定项目申请资格规则时存在一些模糊的地方。在以后的类似活动中，最好能让项目通过 Juicebox 更有意义地将项目的所有权或治理权分配给他们的社区。

Aritizen 上的项目以艺术类项目为主，他们能够使用 Juicebox 协议真的非常好。但是其中有一些项目之前就已经进入加密货币行业，并发行了他们的代币，他们当中的大部分目前并不真的需要使用 Juicebox。因此，Filipv 建议在以后类似的活动中采取更严格的要求，确保参与的项目能够更有意义地利用 Juicebox 协议，而不是仅仅部署一个项目了事。

总体而言，Filipv 认为相关工作进展顺利，有许多很有潜力的项目。他还认为，Juicebox 项目加速器基金可能是我们迄今为止最好的资助项目之一，很可能会产生一些非常好的结果。

$JBX 现状 -- Jango​

周会上，Jango 分享了他最近撰写的一篇文章，谈论他对 JBX 代币的一些想法。

Jango 觉得，随着回购委托的安装使用，现在是合适的时机来反思我们社区的当前发展状态，社区有治理责任并管理着 JBX 持有者共同组建的金库。一直以来我们利用这个金库做很多了不起的事情，但我们也需要时常停下来进行反思。

感谢所有 JBX 持有者的耐心，是他们让我们走到今天并一直推动我们向前，使我们得以完成大量的版本控制工作，从而真正实现协议最近这些跨越式发展。我们还需要多一点时间来理解用户的体验，以便让更多人在这里启动项目、建立社区并确定社区的各种需求。

目前我们的金库里大约有一百万美元等值的以太币，按目前的水平每两周大约需要支出 12 万美元。过去的几年里，我们取得了很多的成绩，但现阶段我们需要设法通过 JBX 代币真正推动我们下一阶段包括 Bananapus、Revnets 和 Juicecrowd 等项目的发展。很大程度上这些都是我们目前工作的延伸，但我们还需要弄清楚采取哪些措施才能真正释放社区的潜在能量。

在 Jango 写的这篇文章中，他反思了对于 JBX 代币的两个价值主张，一个是作为以金库内 ETH 为价值支撑的代币资产，另一个则是作为管理 JuiceboxDAO 及其所有资产的治理代币。

$JBX 作为以 ETH 为价值支撑的代币​

每次有资金流入金库时，都会相应地发行出新的 JBX 代币，也可以通过销毁这些代币从金库里获取资金。

十月份我们部署回购委托之后，收到的付款会中转到去中心化交易所购买代币，直到代币的市场价格与协议的发行价格持平。如此一来，付款人可以获得更好的收益，而保留代币接收人的激励也得到更好的体现。但是如果投资者想要获得最优的 JBX 价格，他们应该去 AMM 而不是在协议上购买，这样就不用承担保留代币的成本。

在过去的一段时间里，我们一直从金库支出费用，因此 JBX 的 ETH 价值支撑越来越低，JBX 的地板价格也由于我们的支出一直不断下降。

$JBX 作为治理代币​

过去的几年里，JBX 作为治理代币也经历了不少起伏，从一开始的一无是处，到现在有了一个可预见性非常强的步调来配置周期、参与治理及执行决策，这个发展对于我们所有建设者来说，是一个巨大的进步，正是这个进步帮忙我们走到了今天。

我们还拥有相当可观的 JBX 代币余额，这是除了金库里的 ETH 之外我们最大的一个资产。Jango 认为，我们可以更创造性地运用这些 JBX 资产，从而赋予网络更多的力量来推动自身向前发展。

Jango 的观察及建议​

我们已经完成了很多基础性的技术搭建，支持以多种方式来实现资金的金融管理。Jango 认为我们开始意识到必须摸索高效增长的途径。同时，我们也有责任通过有利于我们实现使命的方式来管理金库中剩余的 ETH。

如果我们想要赋能 JBX 代币，我们就必须增加而不是减少它的底层资产。这就好像踩钢丝一样，两边都很重要。我们想要向前发展的话，我们所做的工作需要付出的时间、精力、注意力和热情才能实现。我们必须在这里找到一个平衡点，如果我们做不到，可能就需要承担因此带来的后果。

他还建议，我们从保留代币名单移除各个实体，让更多的保留代币流入 DAO 的金库，然后每个人都必须通过提案的形式来进行申请，这比直接向保留代币受益人分配的方式更具可扩展性。

结语​

Jango 认为，我们向未来迈进的时候，同时一个展开创造性思考的机会。这个过程中可能会带来一些痛苦，但这是正常的。

Jango 表示他会尽力带头提出一些建议，尝试建立一些运作的模式，并与外部投资者和其他社区建立关系，争取在财务上也能够实现前进的推动力。

关于 JBX 交易池的看法​

LJ 问及 Jango 对 JBX 二级市场表现的看法，因为 JBX 代币的交易池流动性还比较低。他对 Jango 考虑利用 JBX 而不是仅花费 ETH 的想法表示认同，但他认为我们也应该关注 JBX 的二级市场表现，因为活跃的二级市场有助于吸引更多关注并引入更多零售用户。

Jango 表示同意，增加更多流动性固然可以带来更多价格稳定性，但 AMM 上的价格都是暂时性的，经常发生波动。他表示我们真正可以依赖的是代币的地板价，也就是 JBX 代币的支撑价值，其他都只是源于我们的工作产生的叙事及对 JBX 两种价值主张认可。

医疗帐单的众筹 -- Felirami​

Felirami 最近启动了一个名为 Web3 Aid for Mom's Recovery 的 Juicebox 项目，为他因严重疾病在 ICU 住院的母亲筹集资金。

在周会上，他对 Juicebox 平台及曾向他的项目捐款的人表示感谢。但他也表示，不知道应该如何让更多人知道这个项目来获得更多的帮助来支付他母亲的医疗费用。

TJL 表示，我们目前正在设法帮助项目更好地讲述它们的故事、制定更具激励性的奖励、开展市场推广并启动项目。他邀请 Felirami 加入 Juicecrowd 的 Discord，并承诺将向他介绍最近的 Juicecrowd 01 计划的具体内容。希望能够帮助 Feliram 了解更多促进筹款效果的办法，以便改进他的筹款活动并获得更多的关注。

Juicecrowd 工作报告 -- TJL​

Peel 团队发现， juicebox.money 的目标用户种类过多，存在很高复杂性，因此他们希望能够推出一个专用产品来更好地迎合众筹用户的需求并确保更高成功机率。出于这个想法，Peel 团队着手构建一个更专注于众筹的去中心化应用，也就是 Juicecrowd，以帮助引入一些高质量的项目，同时从更全面的角度来审视筹款活动。

Peel 从整体的角度来分析筹款活动成功所需要具备的各种要素，比如他们的故事、使命、愿景，项目的结构，贡献者的激励方式，以及他们的营销方式等等。除了这个细分用途 Juicecrowd 去中心化应用，他们还启动了一个孵化计划，招募高质量项目并帮助他们完备众筹活动所需的各种细节。

截至本次周会，他们已成功收到了 16 个项目申请参加 JC01 计划。目前项目的申请截止期限已经延长到 11 月 8 日，希望最后能收到 20 个以上项目的申请。

TJl 预计他们下周会推出一个测试项目用于展示用途，而 JC01 计划将于两周后正式启动。

此外，他对 Matthew 和 Brileigh 为推出计划以及吸引项目参与所做的工作表示赞赏，同时也肯定了 Wraeth、Aeolian 和 JohnnyD 在整合 Juicecrowd 项目页面所做出的工作。

Juicecrowd 海报及铸造 -- Matthew​

Sage 和 Strath 合作制作了 Juicecrowd 01 计划的宣传海报，这张海报在 Zora 上免费提供铸造。Matthew 认为我们应该不断尝试各种不同的策略，寻找链上展示我们部分艺术作品的方式，而不是像目前这样，仅限于网站上的使用。

Jango 认为制作海报的活动非常好，他认为 Juicecrowd 不仅是专为众筹而设计的产品，也是设定时间期限、朝着目标努力的一种尝试，同时也是在推广中开展创意活动的体现。

Revnet 介绍 -- Filipv​

Filipv 最近在 Revnets 模拟网站上更新了关于 Revnet 的详细介绍，具体说明什么是 Revnet，以及为什么人们应该创建和使用 Revnet 。Filipv 表示他会尽量使这些信息尽可能普遍适用于各种不同的项目。

Artizen 项目工作报告 -- Filipv​

上周，Artizen 项目的项目方 Nene 和 Filipv 一起对项目进行重新配置时，前端出现了一个小问题，导致了该项目新筹款周期的赎回率错误设置为 100%。

为了避免这个项目发生意外情况，大家决定将该项目归档并创建一个新的配置正确的 Artizen 项目来替代旧的项目。由于旧项目的周期时间配置为 101 天，金库里的资金短时间内无法取出，Jango 和 Filipv 决定先用他们的个人资金进行垫付，稍后再向 DAO 发起提案要求报销这些费用。

Wraeth 和 JohnnyD 创建了一个 PR 并已经进行合并，目前这个错误已经得到解决。可以在这里查看有关发现、处理这个问题的整个过程。

Tjl 稍后会与 Nene 碰头，一起审查申请 Juicebox 和 Artizen 配套基金的项目，有任何最新情况将会进一步报告。

Bananapus 工作报告 -- Jango​

Jango 说，Bananapus 对 Juicebox V3 协议的分叉，也就是 V4 协议的开发可能会在本周内完成。下周合约团队将会进入密集的合约审核模式。内部审核完成之后，他预计我们将会安排一次 Bananapus 合约的Code4rena 比赛来进行公开的审计。

Bananpus 项目将有可能在 11 月底正式上线，届时至少会先完成在测试网络的部署。由于 Nowonder、0xBA5ED 和 Dr.Gorilla 进行的各项审查工作，Jango 表示他对合约及之后的部署充满信心。

Origin Ether 整合 -- Slagathor​

Slagathor 来自 Origin 协议，他在会上提到希望能在 Juicebox 的后端集成他们的 Origin Ether 代币。根据他的介绍，Origin Ether 是部署在以太坊主网上的一个收益聚合器，本质上是由 ETH 和几种 LSD（流动性衍生品质押）提供 1:1 支持。用户的抵押物将会投入到部分协议上获取收益，再把这些收益返还给 OETH 代币的持有人。

Jango 表示，我们正在探索跨链运营，并计划以一种细分的模式实现多种代币的支持。希望在不久的将来，我们可以为 Origin 协议提供一条更为直接的途径，让他们无需要任何许可就能够把他们的代币整合到 Juicebox 协议上。

Bananapus 工作报告​

Bananapus 项目将使用和部署的 Juicebox 协议分叉仍在项目的 GitHub 代码库中进行开发工作。其中最重要的 PR （拉取请求）是一次性配置多个周期，其他则主要是出于方便整合和多币种支持的考虑。

根据 Jango 的说法，Bananapus 的 Juicebox V4 协议分叉将会在以太坊主网和 Optimism 进行部署，部署前将分别先在相应的测试网络进行测试工作。

Bananpus 开发的具体路线图可以参考 Jango 发起的关于资助 Bananpus 项目的提案，该提案已在上一个周期获得 DAO 的正式批准。

Bananapus 的质押奖励组件的开发相对比较复杂。Jango 认为我们可以让它的工作逻辑紧密并且合理，这样人们就可以获益于他们所质押网络的发展。

Filipv 表示，目前在 Bananapus GitHub 库里的前端（bananapus.com 仓库）最初只是基于一个项目与合约交互时基本测试的需要。如果 Bananapus 由多个项目跨多条链使用，目前的设计就很难满足需要，我们可能必须开发更好的版本来提供使用。

Juicecrowd 工作报告 -- Matthew​

目前已有一个项目申请参加 Juicecrowd 01 筹款孵化活动。这个项目名为 Brume Wallet，目的是要开发一个内置实现 Tor 协议的私人以太坊钱包。

这个孵化活动的申请截止日期为2023年11月1日，Matthew 预计届时我们将会看到有更多的项目提交参加申请。

他介绍说，活动截止日期之后，团队将从收到的申请中挑选出最终能够参与这个活动的项目，然后会向这些项目开放 Juicecrowd 项目的创建流程。所有 Juicecrowd 项目创建完成之后，将在 Juicecrowd 页面上进行公开展示。

尽管 Juicecrowd 去中心化应用的最终目标是要实现完全无需许可的项目创建，但团队希望早期从一组项目开始。这样做的想法是为了保持早期使用 Juicecrowd 项目的高质量，团队将会所有项目提供大量的支持、指导，尽可能帮助它们更成功完成筹款计划，以便 Juicecrowd 能够创建一些优越的过往筹款记录，希望有助于将这个产品推向更广泛的受众用户。

在 Juicecrowd 上启动项目的运作方式与在 Juicebox.money 上创建项目的完全相同，只是 Juicecrowd 项目创建流程将更简化，并专门针对众筹的需求进行了一定的优化。代币经济学方面，这些项目将不会有 ERC-20 代币的发行，捐款者可能会收到一个 NFT 来证明他们对项目做出的贡献。

Matthew、Brileigh 和 Filipv 还讨论了与不同的加密组织合作，或申请与多个L2链（如BASE、Arbitrum 或 Optimism 等）合作配套基金的可行性和能够带来的好处。他们一致同意，值得尝试与其他 L2 开展合作，扩展 Juicecrowd 的运营范围。

回购委托工作报告 -- Jango​

回购委托部署到 JuiceboxDAO 项目已经有一段时间了，Jango 表示到目前为止一直运行良好。他近期计划发起一个提案，对回购委托的某些参数进行微调，并向相关的 AMM 流动池添加更多流动性。

如果其他项目想要部署回购委托，我们也可以帮助他们进行设置。等近期所有的 Revnet 都启动之后，这些项目也将会自动部署好回购委托。因此，我们预计会有更多的项目对回购委托这个产品开展实际的应用。

管理我们 Juicebox.money 的前端团队 Peel 也在努力开发，争取在网站显示回购委托启用时从 AMM 交易池实际兑换到的代币数量。

治理合约实现的讨论​

Jigglyjams 在会上提出，我们在 Bananapus 项目中是否仍然有使用治理合约的需要。

Jango 表示，目前正在使用的 Bananapus Juicebox 项目属于临时性质，用于管理 Bananapus 的开发工作。这个项目的治理原计划以 Revnet 试验的形式在链上开展，而 Revnet 属于无项目方的项目模式，无需进行治理。

但是 JuiceboxDAO 预计将在 Bananapus 的 Revnet 启动后获得大量 $NANA 代币，而这些代币将由 JuiceboxDAO 的多签进行管理。虽然短期内不需要考虑太多，但 Jango 对长远探索如何用 JuiceboxDAO 持有的 $NANA 代币来开展链上治理表示了深厚的兴趣。如果 Bananapus 项目获得成功，并且 JuiceboxDAO 拥有大量 $NANA 代币，则需要进行一定的处理，例如分发给 $JBX 持有者、共同治理或进行某种代币兑换等等。

Jango 认为，我们的最终目标肯定不是由六个多签成员来执行 DAO 的各项决定，而是要争取链上治理的真正实现。如果以后试验取代多签的方向，那么长时间锁定代币来获得治理权限，或者让解除锁定取回代币更加正式化等想法会更有意义。但他同时认为，Revnet 才是我们努力向前发展的终极目标所在。

Juicecrowd 工作报告 -- Tjl​

在 Peel 团队构建 juicebox.money 网站的过程中，他们留意到，某些特定的众筹案例，项目启动之后通常需要一些协助来吸引关注，而 juicebox.money 上的某些功能对这个方面诉求的针对性并不高。因此，Peel 团队开发了一个新的去中心化应用 Juicecrowd，用于细化的众筹用途。

Juicecrowd 应用部署的同时，他们还推出了一个名为 Crowd 的活动，每次接受最近 10 个项目提交申请，帮助他们创建和完善自己的 Juicebox 项目，对他们的宣传给予支持，在每次为期 30 天的活动期间让他们获得尽可能多的曝光，从而帮助项目获得发展所需的动力和资金。

TJL表示，感谢 Peel 团队过去两周的出色工作，感谢 Matthew 和 Brileigh 创建 Juicecrowd 01 活动，也感谢 Filipv 给予的支持。

Artizen 合作 -- Nene​

提议 Juicebox 和 Artizen 一起合作建立配套基金的提案已经获得批准。

按照 Nene 的说法，Artizen 推出了 Artizen 基金的第三季比赛，其中有超过 50 个项目符合申请 Juicebox 项目加速器的资格。接下来他们将计划对这些项目进行引导，帮助它们创建自己的 Juicebox 项目，用于接收 Artizen 基金的资金。

Tjl 认为此举对整个生态系统是个利好，能够吸引一批艺术相关的项目，同时与 Artizen 建立合作关系。他预计最近会有许多项目进入 Juicebox 并开启他们的筹款之旅。

Nene 介绍说，所有款项将首先支付到 Artizen 的 Juicebox 项目，然后通过创造者自己的 Juicebox 项目分发给他们。

此外，Nene 表示他们将通过 Juicebox 协议推出 Artizen 代币，并且非常期待把社区的所有权及资金与投资者和社区一共分享。

更名计划工作报告 -- Filipv​

我们的合约团队最近致力于 Juicebox 协议的一些升级，用于 Bananapus 项目的 L2 部署。团队同时讨论了更改合同中某些名称的可能性，因为有些合约中使用的术语与前端及其他地方的不同，可能会让刚接触协议的开发人员或其他人感到困惑。

Filipv 对一些当前的名称进行了简要解释，并在周会进行简单的投票，让社区成员选择他们认为合适的名称。

ERC-20 vs. IJBTokens​

目前 Juicebox 协议中存在两种形式的代币，一种是内部映射代币，由代币合约进行追踪，另一种是实际按 ERC-20 标准进行领取的代币，Filipv 认为两个版本之间的区别令人非常困惑。他建议我们把它们统一称为 ERC-20 代币，并在所有代币相关的表述中使用 ERC-20，但极少数情况下这种命名方式可能会产生一些误解。

Jango 对这一建议表示反对，理由是代币不一定只是 ERC-20 标准，例如一个 ERC-1155 标准代币也可以封装成 IJBTokenERC20。

这个问题的背景是这样的：在 V1 协议中，内部记账的代币称为票据，而代币合约则称为票据窗口，从而与已领取代币形成区别。在 V2 协议中，我们认为票据这个叫法令人感觉困惑，因为大家把两种形式都统一看作为代币，因此票据窗口改成了代币合约，同时用未领取代币和已领取代币来区分它们的不同状态。

Project Payer vs. Pay Relay vs. Payment Router​

项目支付器指的是将资金转发到项目的合约，例如，以太坊支付到这些合同之后，将会被转发到各个项目。

Filipv 提供了一些名称的选项，如支付中继（Pay Relay）、资金转发器（Fund Forwarder）、支付路由（Payment Router）等。

Issuance Reduction Rate vs. Decay Rate​

发行减少率以前称为折扣率，但发行减少率这个叫法似乎并没有被广泛采纳。

Filipv 认为“衰减率”似乎是一个好的替代方案。

Funding Cycle vs. Cycle vs. Ruleset​

我们现在使用筹款周期或周期来定义一个项目的一组规则，这组规则会以周期时间为有限期限，如果项目没有设置周期时长，则会一直生效至被更改。

Jango 认为 Ruleset （规则集）或许可以更准确地描述这个概念，但这个叫法跟我们当前讨论时的表达方式有些差异。

Ballot vs. Approver​

选票 合约是一个管理项目配置更改的合约，由它来批准或拒绝对项目配置的编辑。

State vs. Approval status​

选票合约的批准或拒绝状态现在称为 State，这个 State 可以是已批准、已拒绝、待处理等。

Weight vs. Issuance rate​

权重（Weight）是我们目前在合约中用于代表发行比率（issuance rate）的术语，而发行比率指的是每个周期一个以太币发行出来的代币数量。Filipv 理解之前把它命名为权重的主要原因是，权重不一定只对应发行比率，因为合约非常模块化，大家可以用其他的方式来调用这个数值。但由于目前为止它的使用仍仅限于代币的发行，所以 Filipv 认为我们应该直接使用发行比率，让这个概念更加清晰。

JBProjects vs. JBProjectNFTs​

JBProjects 是一个 NFT 合约，用于铸造代表 Juicebox 项目所有权的管理权限 NFT 代币。

Operator vs. Admin​

JBOperatorStore 是一个允许项目方地址授予任何其他地址权限来代表他们与协议交互的合约。Filipv 认为我们可以称其为管理员而不是操作员，因为获得授权的地址实际上执行的是代表其他人进行的管理工作。

JBDirectory vs. JBContractDirectory vs. JBContractRegistry​

JBDirectory 这个合约可以看作是项目与它们正在使用的控制器和终端之间的一个映射。Filipv 建议在名称中添加“合约”以明确它合约目录的性质。

JBController vs. JBProjectManager​

JBController 在某种程度上类似于一个表面层合同，人们可以直接跟它进行交互来管理项目的规则和代币等等。人们启动或重新配置项目的时候，就会与 JBController 合约进行交互。另一个可选名称是 JBProject Manager。

Distribution Limit vs. Payout Limit​

特定周期内，可以从项目支付出去的最大金额。

Payment Terminal vs. Payment Processor​

支付终端是管理任何特定项目资金的流入和流出的合约。人们向项目付款或从项目赎回的时候，都会与这个合约进行交互。

Overflow vs. Excess Tokens vs. Redeemable Tokens​

溢出 指的是项目在特定周期内超过分配限额部分的金库 ETH 资产。Bananapus 在不同的 L2 上的部署之后，原生代币可能就不一定再是 ETH，而是 Matic、OP、ARB 等，因此把溢出改称为超额代币可能更可取。

Refund Held Fees vs. Unlock Held Fees​

当项目提取资金到 Juicebox 生态系统之外的时候，需要缴纳提款金额 2.5% 的 Juicebox 费用。项目可以选择在提取资金时启用 Hold fees 功能，将这些费用保留在项目金库内暂时不进行处理。如果项目之后通过“add to balance”方法将这些资金返还到项目金库，这些待收取的费用也将会取消，这些款项就可以再用于项目的赎回或支出。

Process fees vs. Collect fees​

Filipv 认为，启用 Hold fees 功能时，费用暂时保留在项目的金库余额内，因此从 JuiceboxDAO 的角度来看，“收取费用” 将比“处理费用” 更为准确。

Data Source vs. Data Provider​

数据源是一个可以在发生向项目付款或从项目赎回的时候提供某些自定义数据的合约。支付或赎回发生之后，数据源可以选择性地对委托合约，实现委托接口或定义执行某些自定义功能函数的另一个合约，进行调用。

Delegate vs. Hook vs. Callback​

委托合约就是由数据源进行调用的扩展合约。

Revnet 模拟 -- Filipv​

Revnet 是 Jango 及其他成员最近致力于开发的一个概念，它的思路是创建预先设定好各项参数的无项目方项目，让项目随时间的发展按照这些预设的规则来自行演变。同时还会视情况需要部署回购委托，把项目收到的付款中转到 AMM 交易池购买代币。

想要搞清楚所有的参数怎样协同工作不是一件容易的事情，所以 Filipv 开发了一个Revnet 模拟器，让大家可以输入一些参数来观察 Revnet 在模拟状态下如何进行演变。现在可以到 sim.revnet.app 使用这个Revnet 模拟器。

参考社区成员 Kmac 的建议，这个模拟器设定为可以在模拟参数区域输入相同的随机种子，使随机产生的买入卖出代币数量具有确定性。因此，其他参数不变的情况下，即使用其他计算机也可以通过相同的随机种子让图表完全一致，这样可以更容易对某些场景进行再现。

按住键盘上的向上箭头来增加流动性池的部署天数，可以看到这些图表随时间变化的动态效果。

Filipv 正在考虑添加导出或导入所有模拟参数的功能，让大家可以将这些参数分享给其他人进行比较。他表示会先在 revnet.app 实现 JSON 文件的兼容，希望以后也能够在 Nance 或 juicebox.money 的前端得到支持。Jigglyjams 建议，除了文件导入/导出功能之外，还可以考虑把模拟参数编码成 Base64 URL 形式，也能够实现模拟情景的轻松复制。

回购委托工作报告 -- Jango​

回购委托已经部署到 JuiceboxDAO 当前的周期，目前工作正常。如果有人向 JuiceboxDAO 捐款，或者其他项目向生态外付款从而需要支付 Juicebox 费用时，他们都会因此而获益，因为付款相应获得的 JBX 代币更多。但这样做的代价是，因为支付进来的款项都中转到了二级市场去购买 JBX，JuiceboxDAO 金库的 ETH 余额将不会再持续增加。

JBX 的能量到这个阶段得到最大的释放。随着项目量能同时向上发展，JBX 刺激生态系统向前发展的作用现在变得更具有实际意义。

下一步我们将计划与 Juicebox.money 整合推出支出流程的报价机制，确实人们可以以最优的价格获得代币。最近也有一些人咨询是否可以把回购委托部署到他们的项目上面，我们会持续关注这方面的需求，希望能从合约开发及用户的角度来继续对这个产品进行调整。

MEV Sandwich MEV 三文治攻击​

如果 Juicebox 的项目向生态之外分配支出，需要向 JuiceboxDAO 支付 2.5% 的 Juicebox 协议费用，回购委托会把收到的费用跳转到 AMM 池购买 JBX 代币，这个时候可能会受到 MEV 机器人的三文治攻击并被盗取去一定的价值，除非触发分配支出交易的地址在钱包内配置了反制 MEV 的 RPC。

造成三文治攻击的原因是，以协议费用形式支付到 JuiceboxDAO 的款项不带有元数据，我们无法指定这些费用应该按什么价格去购买代币，所以回购委托合约在这里使用了 TWAP （时间加权平均价格）预言机来盯住交易池最近的价格。

这个 TWAP 预言机有两个参数我们可以进行调节。第一个是 TWAP 的时间窗口，例如 30 分钟或 24 小时等，这个指的是回购委托向前取值的时间长度，再用得出的平均值来决定执行交易的价格。第二个参数则是我们可以接受从这个平均价格偏离的滑点范围。

通过这个参数，我们可以自动确定期望的成交价格。但期望价格和实际价格之间的差异仍可能存在套利的可能性，尤其是波动性比较大或者池子比较浅的时候。如果中转到 AMM 交易池的 Juicebox 费用是 10、100 或 200 美元的规模，同时流动性深度有 3 万美元左右的话，交易造成的冲击不大，套利的机会也相对比较小，不太会出现 MEV 攻击。只要交易价值相对池子的流动性比较低，或者大家像 Jango 一样向池子添加流动性，MEV 三文治攻击的机会就会慢慢地减少。

关于分配机器人的问题​

最近社区内有些想法，考虑我们是否应该开发一个机器人来监控协议内的支出分配行为并对函数进行调用，避免 MEV 机器人的调用和攻击。

Jango 以最近 JuiceboxDAO 的分配支出为例，这次支出产生了 1.94 ETH 的 Juicebox 费用（是的，包括 JuiceboxDAO 在内的所有项目，只要向生态之外付款，都需要支付 Juicebox 费用）。这次 MEV 攻击的总交易额大概在 8.5 万美元左右，1% 的池子产生超过 800 美元的流动性费用。类似这种行为会鼓励人们向池子添加流动性，相应地就会降低之后的套利机会。

我们当然也可以选择自己开发一个机器人来利用我们信息不对称的优势，但 Jango 认为我们还有比这个更重要的事情值得去做。当然，如果有人对这方面感兴趣，也可以发起相关的提案，只要社区同意，他是持开放的态度的。

Jango 计划下个周期发起一项提案，建议 DAO 向 JBX 流动池添加更多流动性，从而降低回购委托工作时受到 MEV 套利攻击的可能性。

Juicecast 播客工作报告 -- Matthew 及 Brileigh​

Matthew 及 Brileigh 发布了新一期的 Juicecast 节目，采访嘉宾是来自 Seed Club 的 Peacenode，他们在节目中谈论了 Peacenode 在 Seed Club 作为创意总监的具体工作情况，他如何帮助建立 Seed Club 品牌，以及他们社区如何通过创造者带动的维度来开展品牌塑造工作。

Matthew 还表示，他们正计划与 Seed Club 展开某种形式的合作，争取吸引该社区一些早期项目的创建者过来 Juicebox 创建他们的项目。他们制作这一系列的播客，目的就是要在与其他社区之间建立起沟通的渠道，并在将来能够利用这些联系来开展工作。

Brileigh 补充说她更喜欢跨社区生态的思路，比方说，项目可以在其他平台上开展筹款并进行摸索，之后也可以转到 Juicebox 来管理他们的金库，或者将 Nance 用于他们社区的治理。项目可以创建于某个平台，但发展起来之后，他们应该可以自由地使用各种不同的工具，例如 Juicebox 提供的各种工具，来进一步推动项目的发展。

来自 Thirsty Thirsty 的 Bruxa 同意，与 Seed Club 的合作机会可能对建立相互之间的关系极为重要，尤其是在围绕 DAO 及金库构建的教育引导方面。Jango 也对以播客的形式通过开展对话来维护社区之间关系的重要性表示认同，即使这些努力在短期内未必会获得太大的成效。

Nance 工作报告 -- Jigglyjams​

Nance 最近的提案在温度测试阶段收到一些反馈，团队针对这些意见开展了 Nance 系统简单化的工作，以便更易于发展新用户，或吸引新社区来使用 Nance 的服务。

同时，他们还将实现新的提案编辑器，这是一个纯净的 Markdown 编辑器，它将会取代目前在 HTML 格式和 Markdown 格式之间大量进行转换的旧编辑器。旧的编辑器似乎在其他如 Snapshot.org 等的地方会有一些兼容性问题，提案的格式显示有乱码，团队正在努力改善这个 bug 来支持更好的提案展示。

非常欢迎提出关于 Nance 的反馈意见，Nance 团队包括 Jigglyjams、Twodam 和 Zeugh 将会积极朝大家感兴趣的方向展开努力。

Thirsty Thirsty 发展分享 -- Bruxa​

Thirsty Thirsty 社区一直以来都在持续地努力创建新的社区基础架构，特别是围绕他们的 TT 代币。

Bruxa 几个星期前在他们社区内发起了一项提案，要求社区向她分发代币来补偿她所作出的贡献，这个提案获得了批准。他们决定 10 月 20 日让其他 Thirsty Thirsty 的贡献者们也一起为自己的贡献申请补偿。

Bruxa 还说，构建社区治理的以来，她和很多非常酷的人，以及 Juicebox 生态内开发的产品产生过互动，这是一个非常奇妙的旅程。

Juicebox 主题商品的想法 -- Matthew​

Matthew、Brileigh 及 Sage 一直在讨论发行 NFT 的细节，这些 NFT 将用于赎回获取一些 Juicebox 主题商品。同时他们还在敲定的最后细节，希望能制造一些高质量的商品，如连帽衫、T 恤、刺绣图案帽子等等。他们计划把这些商品带到明年二月举行的 ETH Denver 活动上去。

Mathew 还介绍，他们正准备与一个咖啡品牌建立合作关系，争取在咖啡袋上面印上 Banny 的图案。他觉得咖啡是一个进入门槛比较低的产品，因为喜爱咖啡的人群很大，可能比较容易展开推广工作。他们可能将咖啡包装作为一个切入点，慢慢把 Banny 呈现到更多不同的产品上去。