在 Juicebox 上运营的项目需要一些支付终端来降低捐款人付款和赎回时的 gas 费用。

要实现这一点，除主网之外，项目还需要能在很多不同的 L2 上接收资金。

最简单的做法是在每个兼容 EVM 的 L2 环境中部署相同的 Juicebox 协议。这会迫使项目选择他们想要在哪一个 L2 上运行，或者如果他们想要同时在多个网络中运行，则需要自行处理因此引入的复杂性。但凡能够简单易行一点，我猜大多数项目都会希望在所有的环境下运行。

JuiceboxDAO 本身就是在 Juicebox 协议上运行，如果我们在协议层什么都不做，直接采取这个简单方案， 我们也会面临同样的困境。相反，如果我们预先考虑如何调整 Juicebox V2 协议来使我们的跨层运行简单化，可能也会帮助所有选择在 Juicebox 上建立金库的项目轻松实现跨层运行。

一个有效的解决方案将考虑到以下几点：

• 项目不希望把社区和治理分散到各条链上去。不管人们选择从哪条链捐款进来，都应该得到所有成员的欢呼认同，而项目不管在哪一条链上相应分发代币，这些代币都应该同样享有治理项目累积资金的权利。
• 随着时间推移，项目代币的发行价格应在所有可用环境下得到同步。筹款周期更新后，代币的分发权重经常会发生变化。除非有意为之，否则不应该存在跨链套利的机会。
• 筹款周期的重新配置在所有的环境中，要么都被批准，要么都被否决。如果一个项目提议在其中一个环境重新配置筹款参数，但最终在投票中未获得通过，那么这一变更在其他所有环境中也不能生效。反而言之，成功的筹款周期重新配置应该在所有链上都得到体现。

请继续关注我提出的关于如何在 rollup L2 中实现这一点的具体建议，也欢迎参与讨论并提出自己的想法，使我们能够就最佳方案达成共识。

我正在对这个问题进行思考，欢迎随时反馈。请在这个讨论组内发表意见，如果看漏了请提醒我，关注到所有内容可能有点难。

ConstitutionDAO 到了需要某种协调的时刻。技术层面上和社会层面上我们都必须作出一些决定，人们将第一次真正有机会用他们的 PEOPLE 代币来发声。

与此同时，我们这些开发者们也有机会来评估和扩展我们目前的工具，以便为将来人们应对类似场景提供最好的支持。

考虑退款方式的设计时我们关注的方面有：速度、安全性、成本、灵活性、方便性，（...？）

对于 ConstitutionDAO 这个情况，可以通过一些不同的方式来处理退款事宜（肯定还存在其他我不知道或不够熟悉的方法）：

通过 Juicebox 进行退款​

步骤：

1. 把这4千多万美元重新转入到 Juicebox 合约。
2. 多签钱包发起一个交易，把 ConstitutionDAO 的筹款周期目标重新配置为 0，以便允许所有代币按相应比例赎回项目金库里的全部资金。
3. 任何人都可以选择赎回他们持有的 PEOPLE 代币。所有希望留下参与建设 ConstitutionDAO 的人则可以保留他们的 PEOPLE 代币，并把资金交给社区来管理。
4. DAO 最终会重新评估自己想要朝哪个方向发展，以及谁来管理多签钱包以代表社区继续金库的运营。DAO 也可以重新评估它是否希望接纳新成员以及接受捐款，等等。换言之，DAO 继续作为 DAO 运作下去。

提示：

• -- 把四千多万美元转回 Juicebox 合约之前，我觉得最好先多找几个人审核一下这些合约。我个人对这些合约是有信心的，但我们要得到社区的信任，还要让社区明白这件事情具有试验性质并存在风险。我希望社区在做这个决定时能够充满信心。为此，我很愿意接下来几天组织一些专题讨论。
• --每个选择赎回的人将要支付跟捐赠时差不多的 gas 费用：相当于30-60美元的ETH。这对于那些捐赠金额和 gas 费用数额差不多的人来说尤其令人不快。
• ++ 这个方案需要做的协调是最少的，每个人都可以按自己的想法、适合自己的时间去采取行动。
• ++ 由于这个 Juicebox 的流程正在进行审计，对于那些已经把 PEOPLE 代币发送到多签钱包的人，DAO 可以开始马上手动向其发放退款。

多签钱包手动发放退款​

我看到 @strangechances, @DennisonBertram, 以及@austingriffith等人提出了这个方案的不同版本。

步骤：

1. DAO 保留大概200万美元来支付退款的 gas 费用。
2. 抓取一个交易快照。在某个区块高度持有 PEOPLE 代币的人，都可以按每100万代币兑换一个 ETH 的比例申请退款。
3. 多签发送交易来满足这些申请，并用保留的资金来支付 gas 费用。
4. 因为 PEOPLE 代币将不再拥有 ETH 作为价值支撑，留下来的 DAO 社区需要重新评估，如果保持 DAO 的运作，社区应该怎样去管理它的代币。

提示：

• -- 多签钱包成员可能要处理高达数千笔的付款。
• -- 大家提出退款申请可能会有一个较长的时间跨度。多签成员要提前做大量的复核和确认工作，而且还要守候一段时间。
• -- 因快照后发生的交易而新增的余额将不计算在可赎回余额内。
• ++ gas 费用会在每个留下的持币人之间平摊。如果预计有足够多的社区成员希望继续持有PEOPLE 代币，DAO甚至可以在捐款金额基础上增加最多60美元来发放给要离开的成员，来补贴他们捐款时支付的交易费用。
• ++ 大家可以选择申请在特定的 L2 网络退款。多签可以批量转账到每个相应的 L2 网络，然后再从该网络发放退款。

多签钱包部署一个 Merkle Distributor 空投​

这是@nnnnicholas的意见。提示：Nicholas 并不是 ConstitutionDAO 捐款成员。@austingriffith也提出了相同的意见。 @strangechances建议使用 Mirror Splits 来执行这个退款方案，并主动提出可以帮忙。

步骤：

1. 抓取一个交易快照。在某个区块高度持有 PEOPLE 代币的人，都可以按每100万代币兑换一个 ETH 的比例申请退款。这个操作叫“抓取快照”。
2. 部署空投/分割合约，并把退款总额发送到合约。
3. 公布把资金重新转入 DAO 金库多签钱包的时间线，让快照抓取的地址来申请退款。
4. 因为 PEOPLE 代币将不再拥有 ETH 作为价值支撑，留下来的 DAO 社区需要重新评估，如果保持 DAO 的运作，社区应该怎样去管理它的代币。

提示：

• -- 这个做法仍然会耗费退款人与通过 Juicebox 赎回方案相近的 gas 费用。
• -- PEOPLE 代币不能再用作对金库的索取权，因为那样的话人们可能会再次领取。PEOPLE 代币将不再拥有正常 Juicebox 项目代币的功能。
• ++ 空投退款的主要优势是可以通过全部或者大部分经过审计的代码来实现，相对Juicebox未经审计的赎回机制提高了安全性。
• ++ 这个做法相对于多签支付 gas 费用来直接发放退款的方案来说，会降低 DAO（即不希望退款的人群）所需支付的的 gas 费用。
• ++ 空投可以设置成允许在 L2 网络退款，但会增加操作的复杂程度。
• ++ 捐款人既可以保留 PEOPLE 代币，又可以获得退款。

…（提交其他想法，把步骤和做法的取舍都列明出来）

一般性提示：

• 在 PEOPLE 代币停止发行之后向 ConstitutionDAO 捐款的人，将会收到 DAO 的直接退款。
• 需要用到交易快照的情形，选择抓取快照时机非常重要。快照时间的选择可以包括 Juicebox 停止接受新捐款的时间、拍卖失败时间或者将来的某一个时间点（即预先宣布交易快照标准）。
• 交易快照用哈希树来抓取并存储到链下数据库或者像Mirror 的 Split那样存到 IPFS 上面，这种做法基于 Uniswap 的 UNI 代币空投 Merkle-Distributor 模式，又或者作为一个以 stendhal-labs或collaboration splitter方式存储的链上事件进行公布。后者可能会比较昂贵，但比 DAO 手动分发退款的方式仍然要便宜得多。

根据项目不同的配置选择，Juicebox 协议内项目的溢出资金可以用于各种不同的用途。

提醒一下，溢出等于项目当前在 Juicebox 金库内的资金数量减去当前周期的筹款目标，筹款目标明确了当前周期可从金库分配给预设地址的金额。项目的代币持有人可在任何时候销毁他们的代币来获得项目溢出一定比例的金额，这个比例受到同样每周期进行配置的联合曲线比率所影响。联合曲线比率为 100% 时这个比例是线性的。

以下是如何配置项目的筹款周期以利用其溢出实现不同金库方案的几点概述：

退款​

如果活动不成功，溢出可用于让全体捐款人获得退款。

以 ConstitutionDAO 为例子，这个项目第一个筹款周期的目标设置为 uni256.max ^(注1)，允许把其在 Juicebox 上累积的所有资金自由转移到预设的地址（Gnosis 多签地址）。筹款周期时长同时被设置为 0， 赋予项目方（还是这个 Gnosis 多签地址）随时触发新的重新配置周期的权限。所有捐赠的 ETH 都会给捐款人铸造相应比例数量的项目代币。

因此多签钱包可以把项目的筹款目标重新配置为 0，再把所有的募集款项注回其 Juicebox 金库内，这样会使项目内的所有资金被视为溢出，也就可由代币持有人领取。联合曲线设置为 100% 的情况下，每个代币持有人可以销毁他们的代币来获得与他们最初捐赠金额相等的 ETH。

怒退​

项目可以利用它的溢出来允许一些失去信心的代币持有人退出并带走部分金库的资金。

只有项目的溢出资金是可供销毁代币来获取的。如果项目的大部分资金保管在多签钱包（或者其他合约/资产）内，这些资金不能计入代币的赎回价值（在 Juicebox V2 会发生变化）。因此项目可以通过把流动资金注回 Juicebox、调整项目筹款目标值以及放松/收紧联合曲线比率，来调整怒退的预期所得。

如果项目使用筹款资金的速度比募集资金的速度要快，又或者项目的代币分发比例随着时间发生了变化，通过 Juicebox 内建机制进行的怒退很可能不能获得与最初捐款时相同的金额。

感谢 MolochDAO 创造了“怒退”这个说法。

现金返还​

出售产品的项目可以利用其溢出为客户提供现金返还的机会。

例如，TileDAO 目前以 0.16 ETH 的价格出售艺术品。当作品铸造出来的时候，销售收入流入 TileDAO 的金库，同时相应地向买家铸造项目代币。TileDAO 可能希望通过赋予代币用途，或许是治理的决策权重，来激励代币持有人来持有这些代币，否则这些持有人可能会赎回代币来换取部分的项目金库资金。这个赎回基本上就是给予艺术品买家的部分现金返还，返还价值取决于项目筹款周期配置的几个方面随时间推移的变化。

可实现利润​

项目可以从任意来源向其金库注入资金，让所有代币持有人可以通过销毁代币来获取这些资金。

最简单的例子是，某个项目通过 Juicebox 项目来购买一样东西，然后转头把这个东西高于买入价再卖出。销售所得的资金可以注回到 Juicebox 项目中去，代币持有人希望的话，就可以去获取这些资金。

全部这些例子一致表明，项目可以做出相应的选择，以便随着时间的推移为其社区提供特定的金库设计。控制代表 Juicebox 项目所有权的 NFT 的地址有权来做出这些选择。代表社区来管理这个责任的不管是普通钱包地址还是合约，都应在社区认为合适的范围内受到审查和追责。

希望这些例子会澄清一件事情：项目使用 Juicebox 协议发行的代币是没有内在价值的。但是，这些代币可以被项目用于决策的用途，决策的结果可以赋予代币价值。这一切都取决于我们随时间推移一起做出的选择，以及我们用来约束这些选择的社会契约和算法合约。

注1：unit256 是无符号整数 256 位类型数字，unit256.max 即这种数字的最大值为 2²⁵⁶ - 1。

JBX 成员资格目前由 602,065,173 个代币来体现：

Jango 持有 118,891,959 个（19.74%） Peri 持有 100,255,206 个 （16.65%） DragonFly Capital 持有 48,048,000 个（7.98%） SharkDAO 持有 30,063,667 个（4.99%） JuiceboxDAO 持有 27,827,807 个（4.62%） 4 个地址分别持有大约 18,500,000 个（3%） 13 个地址的持有数量在 5,000,000 - 15,000,000 个区间 （1-3%） 7 个地址的持有数量在 2,500,000 - 5,000,000 个区间（0.5-1%） 28 个地址的持有数量在 500,000 - 2,500,000 个区间（0.1-0.5%） 64 个地址的持有数量在 100,000 - 500,000 个区间 （0.01-0.1%） 56 个地址分别的持有比例少于 0.01%

成员资格授予给了那些帮助开发协议和建立 DAO 的人，还有通过向金库捐赠 ETH 来支持这些工作的人，尤其是那些在较早的筹款周期提供了任何形式帮助的人。协议部署以来，成员资格已向所有人开放。

在当前第 8 个筹款周期，新老成员每向金库捐赠 10 个 ETH 会铸造以下数量的 JBX：

捐赠的成员获得 2,579,260 个

JuiceboxDAO 获得 416,649 个 Peri 获得 333,319 个 Jango 获得 333,319 个 Nicholas 获得 97,218 个 Exekias 获得 97,218 个 WAGMI Studios 获得 55,553 个 CanuDAO 获得 55,553 个

目前，捐款成员要捐赠 278 个 ETH 才能获得成员代币总量的 10%。

两个月前第 4 个筹款周期期间，向金库捐赠 10 个 ETH 会铸造 3,931,200 个JBX 代币给捐款成员。

每收到 1 ETH 向成员发行的 JBX 代币数量每 2 周减少 10%。按照目前 2 周为一个筹款周期的减少速度再加上 35% 的代币保留率，到第 12 个筹款周期的时候，捐赠 10 个 ETH 就只能铸造 1,692,252 个 JBX 代币了。

观察​

• 建设者和捐赠人都不知道他们捐赠 ETH 获得的代币或者收到的保留代币究竟有什么用。
• 成员资格变贵了。
• 迄今为止，JBDAO 的策略一直是专注于公开建设，同时提前说明高效建设所需要的资源。
• JBDAO里没有人太关注怎样降低成员资格门槛或者如何更大范围地分配成员资格，又或者为什么这个工作值得优先考虑。我们主要讨论的是，如何去为 Juicebox 项目以及那些希望参与改进或者发展这个生态的建议者们解决问题。
• JBDAO 之所以选择 35% 的代币保留率，是为了确保不管 DAO 怎样扩充成员资格都会有 25% 的份额流向管理项目的建设者。如果 DAO 的金库得不到增长，忠诚的建设者就不会成为举足轻重的成员。剩下的 10% 流向 JBDAO 自身，但还没有被动用过。
• 目前 DAO 的松散贡献者和帮助者除了向 DAO 捐赠任意金额之外，并没有其他途径成为 DAO 的成员。
• 可能 DAO 应该降低它的折扣率，这样随着时间的发展，有意向加入的成员的资格能得到体现同时能令他们觉得受到大家的欢迎。
• DAO 把全部的 35% 保留率都分配给自己会挺有意思的，这样它可以分发数量较为可观的入门成员资格给更多随性帮忙的人，以及那些正边埋头苦干边开始认识这个系统但暂时又没计划持久参与的人。DAO 还可以给其他 web3 的建设者分发成员资格，在决定 DAO 应该怎样分配金库的时候，他们可以作为其中富有创意而又深思熟虑的一种声音。

开放式的问题​

• DAO 要怎么有效地分配它的 JBX 份额才能在今天和未来吸纳更多优秀的成员？

资金捐献到 JuiceboxDAO 的金库里 ， 不管是直接付款还是支付费用的形式，就会铸造及分发 JBX 代币。目前来说，铸造出来的 JBX 代币有 35% 保留并分配给预设的地址，剩余的 65% 则分发给付款人。

JuiceboxDAO 保留代币当前的分配情况如下：

JBX 代币的发行数量是没有上限的：捐赠的 ETH 越多，创造出来的 JBX 也会越多，虽然创造的速度会由于折扣率的存在而渐次递减（目前每个 ETH 铸造的 JBX 代币数量每两周递减 10%）。每次付款过后，可供分享的蛋糕都会变大，但同时每个人的蛋糕份额却会轻微地收缩。

.….. 除了那些保留代币名单上的人。在任何特定时间节点，他们的整体 JBX 持有量都会按照金库的增长速度向预设分配给他们的保留代币百分比靠近。这也意味着当前 DAO 总体价值的 35% 集中在这些保留代币持有人手上，而剩下的 65% 则在捐赠或付费那个群体之间逐渐进行长尾分配，先到的受惠更多。

迄今为止，JuiceboxDAO 的保留代币主要分配给那些肩负 DAO 各项运营责任的少数贡献者。最近，DAO 也开始为多签钱包保留代币，用于流动性质押奖励和其他项目的再分配。

展望未来，DAO 协调社区内激励措施的最佳途径可能是来自扩大保留代币池来涵括许多新成员和承诺助力 DAO 走向成功的各项活动，还有一些较小范围的试验性分配。

做好类似 DAO 治理文件中概述的一些基本的预防措施和行动指引，DAO 就应该准备好公平高效地吸收一些有用的贡献者，同时清除那些混吃等死或毫无建树的人。这个流程应当把 DAO 所创造的价值传递给那些积极推动项目发展使命的人，以及那些构建于协议之上并持续支付平台费用的项目。

我非常希望接下来的几个月能看到更多保留代币的分配提案，并期待保留代币受益人的数量能够大幅增加。

题外话​

保留率还会大幅提高恶意并购的成本。 JuiceboxDAO 目前的 JBX 代币的总供应量是 577,516,588 个。当前每捐赠一个 ETH 会新铸造 544,320 个JBX 代币（355,808 个分发给付款人，190,512 个流向保留代币池）。如果今天某人要给自己铸造总供应量 51% 的代币，他就必须往项目金库里投入 3,865 个 ETH。时间越往后，这个代价就会越高，因为代币的总供应量持续在增加而捐赠一个 ETH 能铸造代币数量却持续在减少。

Last update: 9/07/2021

Current focus areas are:

• Risk mitigation
• Protocol upgrades
• Web experience
• Analytics
• DAO relations
• Liquidity pools
• NFT marketplace
• Governance
• Materials

Focus areas​

Risk mitigation​

Goal: Make sure things don't go to zero.

Current team: jango (lead), exekias, peri.

Updates:

• nothing to report.

Help needed:

• Reviewing V2 docs and tests.
• Bug bounties now included in the V2 documentation that's underway.

Protocol Updates​

Goal: Evolve the protocol to be more useful.

Current team: jango (lead), peri, exekias, nicholas

Updates:

• Progress on documentation. JBSplitStore, JBOperatorStore, JBPrices, and JBProjects are fully documented. See Protocol section of docs.juicebox.money.
• Bug bounties now included in the V2 documentation

Help needed:

• More eyes on the docs
• Pursue leads for solidity audits in next 4-6 weeks

Web experience​

Goal: Improve the Juicebox experience both for people starting communities and for communities that are growing.

Current team: peri (lead), jango, exekias

Updates:

• Added feature for JB Project owners to update assets listed in the Project UI
• will eventually support 721 assets, too
• 'Pay' button Call to Action can now be customized
• Rinkeby support
• JB Interface now has its own dedicated repo and issue tracking https://github.com/jbx-protocol/juice-interface

Help needed:

• Backlog of todos https://github.com/jbx-protocol/juice-interface/issues
• Would love to bring on a dedicated person to get familiar with the UI codebase

Analytics​

Goal: Give projects rich insights into their community treasury.

Current team: peri (lead)

Updates:

Contribution pipeline being refined. Subgraph now has a dedicated repo with a streamlined deployment flow.

Analytics roadmap being refined as steps for V2 migration become clearer.

Subgraph Deep Dive

Help needed:

• Work/todos being tracked here https://github.com/jbx-protocol/juice-subgraph/issues

DAO relations​

Goal: Work towards making sure JB projects and the JB community have the resources and attention they need to get started and thrive.

*Current team: nati (lead), zeugh, mieos, nicholas, jango *

Updates:

• Jango and others converting people from DMs into discord members.
• Lots of people coming into the DAO relations channel.
• Pencil DAO created without any interaction with team. BrainDAO and others coming online.
• Idea: Daoification Hackathon to help JuiceboxDAO members feel more comfortable onboarding others.
• Meeting with largest single contributor: Conversation with Tom Schmidt of Dragonfly Capital
• Lots of progress in Notion: Tools section, How to section.
• Meeting notes becoming standardized and recordings much more frequent
• Gitbook docs welcome page and contract addresses added.
• Zeugh bought Sesh pro.

Help needed:

• Project lead on Daoification hackathon where anyone can join in and create a bunch of projects on rinkeby to be more comfortable configuring and reconfiguring a JB.
• Project lead needed to design and implement faster easier way to create "a DAO for your group chat". Can this be done with a Discord bot?Help Needed
• Feedback to Zeugh for discord restructuring.
• Adding info to Tools.
• More people willing to record calls and upload.

Liquidity pools​

Goal: Add support for JB treasury tokens in secondary markets for communities to be able to value their assets better.

Current team: exekias (lead), jango

Updates:

• No updates. Core dev team is focusing on V2 for the time being.
• Might be a good move to fork the BarnBridge rewards contracts instead of the synthetix ones.

Help needed:

• Someone to help test, verify, and deploy the staking contracts.

NFT Marketplace​

Goal: Give JB projects a place to sell digital (and eventually physical) goods which pipe percentages of revenue to any number of addresses or Juicebox treasuries.

Current team: nicholas (lead), jango, peri

Updates:

• Looped in Peri and Mieios for NFTMKT specification feedback meeting.
• Reprioritized NFTMKT, JB devs will do a sprint this coming week, Sept 27, 2021
• Nailed down V1 spec with Peri's help. Updated architecture, replacing submit with list function, which will save on gas.
• Reaffirmed permisionless design of NFTMKT and v2+ roadmap.
• We will also stand up a couple 721 Creator contracts so artists collaborating with JB projects (e.g., Numo with Sharkdao) can create superior NFTs than on the OpenSea creator contract, which is closed source, centrally hosted metadata by default, and a shared contract. We anticipate one 721 contract for closed collections (where token supply is known in advance) and one open minting collection (where artist can add over time). Nico already has a closed collection contract that we can refine. Can also build a simple front-end to make this easy for artist collaborators (and the broader NFT ecosystem).
• We continue to experiment with ideas about spinning NFTMKT off into its own JB project because the opportunity is large, and we believe that small teams working on focused projects are more effective than one overwhelmingly large vertically integrated JB protocol team. Perhaps initially staffed by same dev team as JB. Can focus on NFTMKT and the creator contracts. Could collect a fee for NFTs sold through the marketplace (2.5% like opensea?) or could be free. If it had revenue it would have more opportunity to expand dev team. Also thinking about token-swaps between NFTMKT and JB 📈🤝.
• Increasing belief that NFTMKT will solve the DEX vs JB dilemma facing DEX-traded DAO tokens, where the DEX is always a better price than the JB, by game-theoretic definition. This limits DAOs' ability to fundraise because DEX trades do not affect DAO treasuries. NFTMKT will allow DAOs like Shark to largely replace direct-to-JB appeals. DEX purchases may still offer cheaper DAO tokens than the NFTMKT, but buyers will not get access to limited edition NFTs via the DEXes. NFTMKT will also be more fun and easy to use for NFT acclimated, compared to JB or DEXes which are unfamiliar to many in that space.
• The team is very excited about the promising design specification and roadmap for the NFTMKT.
• Nicholas also discussed with Mieos affordances in the 721 contracts that will enable WAGMI to create NFTs on behalf of client DAOs. Achievable design requirements even within the V1 spec.

Help needed:

• Review read methods & TheGraph events with Exekias or Peri this coming week
• Nico x Jango will collab to finalize v1 NFTMKT solidity
• Nico to talk to Pencil DAO

Governance​

*Goal: Plan how we make decisions within the community. *

Current team: 9birdy9 (lead), zheug, jango, unicornio

Updates:

• New voting process
• Finalized proposal process
• New governance process:

Governance

Includes Proposal Templates for each common type of proposal.

All JBX holders participate in votes that affect big picture JBX variables.

Changes to recurring payouts are voted on by addresses currently receiving payouts as they have greatest insight and are most affected by such changes.

Changes to reserved token allocation voted on by addresses currently receiving reserved tokens as they are most affected.

Addresses receiving payouts are expected to vote.

• Discussion about whether large token holders and people on reserved list should have max voting capacity or some quadratic strategy that limits outsized impact.
• First trial of these new templates in current governance process.
• @9birdy9's trial payout proposal is the first proposal sent to snapshot according to these forms.
• FC5 reserved JBX tokens will be passed without a formal snapshot for lack of sufficient time to complete our governance snapshot process. We will use snapshots for future reserved token proposals.
• Creation of BANNY gov participation incentivisation token — An airdrop is in the works.

Help needed:

• Refining governance process:
• Creating informational foundations to keep people up to date on governance proposals/timelines.

Materials​

Goal: Videos/visuals/memes/stuff that radiates Juicebox vibes.

Current team: WAGMI studios

Updates:

• WAGMI producing cultural content
• Published overflow video

Help needed:

• Feedback on content
• How can WAGMI help juicebox projects launch
• Helping onboard
• Developing visual identity (cultural material)

Co-authored: jango, peri, exekias, nati, nicholas, zeugh

Current focus areas are:

• Risk mitigation
• Web experience
• DAO relations
• Analytics
• Liquidity pools
• NFT marketplace
• Governance
• Protocol upgrades
• Materials

Focus areas​

Risk mitigation​

Goal: Make sure things don't go to zero.

Current team: jango (lead), exekias, peri.

Updates:

• No new bugs/problems discovered in the contracts.
• New repo where security issues are documented here.
• Wallet connection issues in the front end solved. One remaining bug where connecting wallet from the projects page sometimes causes the beneficiary field of payments.
• DefiYield auditors seems to have dropped off. Need to follow up again.
• Focus on security now moved to V2. Documentation, tests, audits, etc.

Help needed:

• It'd be great if more folks could help write tests and review the code and documentation as it gets done. We should collaboratively mold this into its final, secure form.

Web experience​

Goal: Improve the Juicebox experience both for people starting communities and for communities that are growing.

Current team: peri (lead), jango, exekias

Updates:

• New analytics data in project dashboards. Still room to grow, more data sourced into The Graph and ready to use.

• New wallet connection integration. Can now connect with many other wallets with BlockNative integration.
• Progress on Github issues backlog.
• Wording in the interface being reconsidered:  "staking" vs "claiming".
• Researching different UIs for different treasury types.

Help wanted:

• Backlog at https://github.com/jbx-protocol/juice-juicehouse/issues

DAO relations​

Goal: Work towards making sure JB projects and the JB community have the resources and attention they need to get started and thrive.

Current team: nati (lead), jango, nicholas, mieos, zeugh

Updates:

• Gitbook updates underway. Walkthrough, explanation of processes.
• Working with Whiteboard crypto, UltraDao, BeatsDao.
• Focusing on established DAOs. Might refocus to newer DAOs later.
• People should forward questions from #support and from other JB projects to Nati to aggregate into docs.

Analytics​

Goal: Give projects rich insights into their community treasury.

Current team: peri (lead), buradorii

Updates:

• Most updated in the UI under the "Web experience" focus.
• Experimenting with what data can be accessible in the UI.
• No updates on Flipside or Dune analytics.
• People want to see current token holders for each projects.
• People want to see current FC vs upcoming FC.
• People want to see the price the treasury token is being sold at over time.
• People want to see the percent of the tokens that they will own at the time of making payments.
• People want to be able to play out funding cycle scenarios before making reconfigurations.

Open to help:

• Index more Subgraph events.
• Display discount rates (tokens/ETH) of past funding cycles.

Liquidity pools​

Goal: Add support for JB treasury tokens in secondary markets for communities to be able to value their assets better.

Current team: exekias (lead), jango

Updates:

• Experimenting with Synthetix staking rewards contracts: https://github.com/jbx-protocol/staking-rewards.
• Fleshing out UI prototypes:

Help wanted:

• Comms with JBX project owners (e.g., SHARK) to understand their needs from a staking reward/LP perspective.
• Devs with staking rewards expertise.

NFT Marketplace​

Goal: Give JB projects a place to sell digital (and eventually physical) goods which pipe percentages of revenue to any number of addresses or Juicebox treasuries.

Current team: nicholas (lead), jango, peri

Updates:

• Big demand from SharkDAO (and others?).
• Draft of contract looking good.
• Plan for V1 is no UI on juicebox.money, make bare bones JS SDK/library with/for Shark to build a NFT MKT into their forthcoming website.
• Need to finalize what will be included in v1, and what won't.
• Specification draft
• Github repo (private for now)

Goals:

• Finalize spec for v1
• Get a working v0 implementation on Rinkeby by Monday 2021-09-13 EOD
• Get a basic 721 contract together to mint NFTs that we can submit to the marketplace

Help needed:

• Jango will help with contract implementation and testing (thank you –nicholas)
• Next week open to help starting building a JS SDK

Governance​

Goal: Plan out how we will make decisions together.

Current team: zheug (lead), unicornio, 9birdy9

Updates:

• Trying coordinape to test a reputation system. The epoch system feels good, didn't give us the easy integration to voting that we needed after the epoch.
• We're still wroking on our basic model for how to make decisions. Need to balance governance power between token holders and reputation/contributions but we haven't got a way to test it yet.
• We can, at the moment, take the csv of reputation distributed after the Epoch, but are still looking on how to import those in a strategy to snapshot. Need help from more dev oriented folks to communicate coordinape results onto snapshot.

Help needed:

• We need some dev/snapshot help to integrate our new governance system into a snapshot strategy.

Protocol upgrades​

Goal: Evolve the protocol to be more useful.

Current team: jango (lead), peri, exekias, nicholas

Updates:

• V2 has been announced here.
• Reviewed V2 with Peri, Exekias, and Nicholas, got very valuable feedback that is being iterated on.
• Docs for V2 are in progress here.

Help needed:

• Same as in the "Risk mitigation" section.

Materials​

Goal: Videos/visuals/memes/stuff that radiates Juicebox vibes.

Current team: WAGMI studios

This is a new section that will have updates next time

现状​

首先：非常感谢过去一个月来使用过第一版 Juicebox 协议的所有人。可以看到大家对这套充满实验性的、未经测试的合约和它的用户体验抱有相当的信心，希望它能帮助你们顺利地实现你们的愿景。协议已经帮助一批项目创建了他们的金库和社区，而这些社区反过来又帮助 Juicebox 扎根于以太坊社交层这块肥沃的土壤。

我一直在观察每个项目和协议的交互情况是怎么样的。我参加了一些令人激动的讨论并看到JB让一些想法和创意得以落地，也在一些讨论里不幸地获悉协议并不支持某些提出来的奇思怪想。我亲眼目睹了有人在几小时内就成功创建项目并募得数百个ETH， 也看到有人刚一打开页面就放弃了念头只因为他们点击了按键却丝毫没有反应。上线短短数周，让我对运行良好的方面有了大致的概念，同时也列出一张需要改善的工作清单。

我们的大方向是逐步稳定地推进这些改善工作。但基础合约层的工作一开始就要跨越式进行，以便最终进入一个稳定的状态，因为创新正不断发生在后面的应用层。Juicebox V2就是第一个大的跨越。其目标很简单：支持更多创新并消除所有摩擦点。

Juicebox V1设计思路是基于社区和项目方动机相背这一假设之上的。使用Juicebox就意味着项目方承诺接受一些特定的限制，这样项目的社区会更有信心支持项目玩法的财务安排。项目方不能随意铸币，不能规定每捐赠一个ETH能发行多少代币，不能限制参与筹款的人群，也不能暂停项目。

事实上这在基础协议层就是个错误的假设。如果社区和项目方方向一致，展示全面创新必须有灵活性来加持。事实证明，大部分社区都渴望建立一个既符合社区特质又能在玩法上与众不同的定制金库策略。

但是项目往往没有技术资源来开发、测试和验证这些解决方案。这是 Juicebox 一直以来为人们提供的一项核心价值，同时提供的还有简洁高效的用户界面，方便社区成员的加入及持续参与。迄今为止，Juicebox 所消除的各种摩擦成本证实了引入金库策略约束条件的合理性。

我们来看看现在能否做得更好一点。

提议的变更​

自带铸造/销毁策略​

你将可以自带合约，合约里概述了你要向社区提议的玩法。你既可以用现成的策略即插即用，也可以自行编写能实现你最疯狂想法的策略。

编写一个策略可以很简单，也可以要多复杂有多复杂。但是必须要提供一个遵守 IFundingCycleDataSource 接口的合约。你可以提供一个策略来决定有人向你的项目付款时怎样处置，也可以提供一个策略用于有人赎回金库代币的场景。

以下是围绕付款来编写策略的工作原理：

你可以添加一个数据源合约来作为一个筹款周期的参数。你的数据源必须提供一个实现以下方法规范的函数。

function payData(
    address _payer,
    uint256 _amount,
    uint256 _baseWeight,
    uint256 _reservedRate,
    address _beneficiary,
    string calldata _memo
)
    external
    returns (
        uint256 weight,
        string calldata memo,
        IPayDelegate delegate
    );

该函数从 Juicebox 协议中接收到一些参数，并需要返回一些参数。

输入：

• _payer 是支付 ETH 的地址。
• _amount 是项目收到的 ETH 数量。
• _baseWeight 是支付行为发生时的筹款周期的权重。这个权重等于前一个周期的权重乘以前一个周期的折扣率。每个项目的第一个筹款周期的权重都是10²⁴。
• _reservedRate 是付款期间筹款周期的保留率。这个百分比的最大值是200。
• _beneficiary 是付款人指定的接收金库代币的地址。
• _memo 是付款人在付款中包含的说明。

输出：

• weight 是 Juicebox 协议在铸造金库代币时应该使用的权重。铸造的总代币数等于amount*weight，其中两个变量都应当是18位精度小数。铸造出来的代币，部分分配给_beneficiary，其余的将按照_reservedRate 分配给保留代币受益人。
• memo 是包括在协议事件中的备注，该事件将作为支付的结果被发出。
• delegate（委托） 是遵守 IPaymentDelegate 接口的合约的地址。如果提供了一个委托，一旦完全处理了付款，该委托将收到 Juicebox 协议的一个回调。如果你不需要这个功能，你可以返回零地址。你的委托合约应该实现的回调如下：

function didPay(
    address _payer,
    uint256 _amount,
    uint256 _weight,
    uint256 _count,
    address _beneficiary,
    string calldata memo
) external;

• _payer 与传递到你的数据源中的相同。
• _amount 与传递到你的数据源中的相同。
• _weight 与从你的数据源返回的相同。
• _count 是为 _beneficiary 铸造的代币的数量。
• _beneficiary 与传递到你的数据源中的相同。
• _memo 与从你的数据源返回的相同。

在这里可以找到所有这些部分组合在一起的 recordPayment 函数。

数据源和委托可以类似地提供给筹款周期，形成 recordRedemption 函数：

function redeemData(
    address _holder,
    uint256 _count,
    uint256 _redemptionRate,
    uint256 _ballotRedemptionRate,
    address _beneficiary,
    string calldata _memo
)
    external
    returns (
        uint256 amount,
        string calldata memo,
        IRedeemDelegate delegate
    );

输入：

• _holder 是正在赎回的代币持有人.
• _count 是赎回的代币数量。
• _redemptionRate 是赎回时，当前筹款周期的赎回率。
• _ballotRedemptionRate 是指如果该项目目前有一个活跃的筹款周期重新配置投票合约，则应该使用的赎回率。
• _beneficiary 是指赎回者指定的地址，该地址用于领取赎回代币获得的金库ETH。
• _memo 是赎回者在赎回中包含的说明。

输出：

• amount 是指赎回/销毁 _count 枚代币之后应该从金库发送给 _beneficiary 的 ETH 数额。
• memo 是包括在协议事件中的备忘录，该事件将作为赎回的结果发出。
• delegate（委托） 是遵守 IRedemptionDelegate 接口的合约地址。如果提供了一个委托，一旦 Juicebox 协议处理完毕赎回操作，在金额分配给 _beneficiary 之前，该委托将收到来自 Juicebox 协议的回调。如果你不想要这个功能，你可以返回零地址。 你的委托合约应该实现的回调如下：

function didRedeem(
    address _holder,
    uint256 _count,
    uint256 _amount,
    address _beneficiary,
    string calldata memo
) external

• _holder 与传递到你的数据源中的相同。
• _count 与传递到你的数据源中的相同。
• _amount 与从数据源返回的相同。
• _beneficiary 与传递到你的数据源中的相同。
• _memo 与你的数据源中返回的相同。 上述组件构成的recordPayment 函数可以在这里找到.

有了这些新的工具，项目可以推出各种金库策略，例如：

• 只接受特定地址的付款。
• 只接受持有某些其他资产的地址付款。
• 根据区块链的状态，提供不同级别的成员。
• 限制支付的最小/最大金额。
• 创建时间加权的奖励。
• 限制社区代币的最大供应量。
• 自定义每收到一个 ETH 所分配的金库代币数量。
• 向新成员铸造 NFT。

...或这些策略的随意组合，以及任何其他你可以通过合约表达的规则。

溢出容差​

之前，一个项目只能获得的筹款周期目标以内的资金。所有超过这个目标的溢出金库资金只有金库代币持有人能够获取。

现在，在指定筹款周期目标的同时，你可以指定一个你可以从项目溢出的资金中按需使用的金额。

这对于分配金库资金时的起停控制非常有用，如 Bug 赏金、一次性捐款、审计、NFT 竞标等。

开放铸造/销毁​

之前，你只能在收到你的第一笔付款之前铸造代币，而销毁只能通过赎回机制进行。所有其它代币都会纯粹通过支付程序根据筹款周期权重而分配，筹款周期权重亦逐渐根据你配置的折扣率减少。

你现在可以随意铸造和分配新的金库代币。所有的代币持有者现在也可以选择销毁他们的代币，无论出于什么原因。

这给了项目更多的灵活性，以他们想要的方式设计代币经济，同时也能让他们使用到 Juicebox 灵活的内置支付机制以及自动分配机制。

保留代币的分配目标​

之前，付款分发对象可以是以太坊地址、其他 Juicebox 项目，以及继承自通用接口的任意合约。而保留代币只能流向以太坊地址。

现在，保留代币的分配也可以指向以太坊地址、其他 Juicebox 项目的所有者，以及继承自这个通用接口的任意合约。

这对于允许项目进行更多可组合的代币分配是很有用的。

支付、提取和赎回都可以暂停。​

之前，项目没有快速的方法来暂停社区与金库的互动。

现在，项目能够单独暂停“支付”、“提取资金”和“赎回代币”的函数调用。并且这些控制选项被配置到了每个筹款周期中。

这给项目提供了一些快速实现某些的金库效果的方法。

可调整的费用​

之前，所有项目的支出都要支付5%的费用。

现在，项目将最多支付5%的费用，具体可由 JuiceboxDAO 调整。还有一个最高收费价格，可由 JuiceboxDAO 调整。

这有助于 JuiceboxDAO 在其生态系统中吸纳更多的项目和实验。

结论​

JuiceboxV2 引入了一套工具，可以实现全新的金库策略。与 V1 相比，不变的是配置被锁定在筹款周期中 —— 如果一个项目在30天的筹款周期中运行，他们可以在筹款周期中指定创造性的动态，但是一旦周期开始，在下一个周期之前就不能进行更改。也和 V1 一样，选择无期限的项目就相当于选择了按需进行任何改变的灵活性。

新合约的实施已经完成，我们现在要做的是记录、测试和审计一切。所有的代码都是公开的，所有的文件和围绕这个升级的对话也将是公开的。

我们需要大家的关注和监督。请不要犹豫，来看一看，帮助我们把事情弄清楚。如果你打算花时间在这上面，请通过 discord来加入我们 DAO 并介绍你自己，这样我们可以确保给你的工作提供合理的报酬。

目前在 Juicebox 上运行的所有项目都将能够无缝地把他们的金库迁移到 V2。

LFG。

第四个筹款周期只需要一些小的改动。所有的重点领域都保持不变，增加一个新的 "协议升级 " 领域。以下是各个领域的情况汇报。

重点领域​

作为一个DAO，我们应该继续关注以下领域：

降低风险​

目标：确保我们做的事情不会归零。

当前团队：Jango（主导）、Exekias

工作汇报：

• 发现一个低严重度 bug, 点击这里了解事情的前因后果，事后剖析在这里
• 由 DeFiYield 执行的基线审计正在进行中。
• 我们仍需规划一个 bug 赏金计划，对发现的不同严重程度的漏洞给予对应的奖励。

UX 改进​

目标：改进项目创建流程及项目面板，并制作相关的模板。

当前团队：Peri（主导）、Jango、Exekias

工作汇报：

• 使用 blocknative 添加其他钱包的 Web3 连接支持。查看这个 PR。
• 更新了网站的 "项目 "页面，支持按 "总收入 "排序。
• 每个项目 feed 都增加了一个数据 feed 来查看每个地址捐赠的 ETH 总额。
• 修复了几个 bug。

项目支持、教育和文档​

目标：确保 JB 项目获得启动和发展所需的资源。

当前团队：Jango（主导）、natimuril、WAGMI 工作室、CanuDAO

工作汇报：

• 帮助 SharkDAO 启动他们金库代币的一个 AMM 资金池。
• 与有兴趣使用 Juicebox 建立金库的一些项目进行了几次讨论。积极研究 ScribeDAO 和 Phlote 的解决方案，FingerprintsDAO、$Loot 和 NiftyTable 的一个项目也在关注之列。
• 技术或流程文件方面没有重大更新。随着我们对项目和贡献者成功所需条件的进一步理解，我们需要在这方面取得进展。

数据分析​

目标：让项目对他们社区金库的状况有深入了解。

当前团队：Peri（主导）、buradorii

工作汇报：

• 在 juicebox.money 的每个项目页面上都添加了一个新的数据 feed，显示每个地址给每个项目的捐款金额。
• 用 Flipside 分析工具制作项目损益图表的工作取得进展。
• 我们尚未给项目提供数据面板。我们仍在努力实现这一目标。

流动性池​

目标：在二级市场增加对 JB 金库代币的支持。

当前团队：Exekias（主导）、Jango

工作汇报：

• SharkDAO 的 SHARK 代币已在 Sushiswap 上启动与 ETH 交易对的流动池，你可以在这里查看分析数据。SharkDAO 的 Juicebox 页面在过渡期间已关闭，计划在未来几天重新开放。
• 正在研究向项目提供一个质押合约来分配流动性奖励。

市场​

目标：为 JB 项目提供销售数字商品（及实物？）的场所，销售收入按百分比分配给任意数量的钱包地址及 Juicebox 金库.

当前团队：Nicholas（主导）、Jango、Peri

工作汇报：

• 研究其他协议分割支付的方式。
• 落实我们准备解决的用户流程。
• 开始研究如何构建合约。
• 开始构思 UX 设计。

治理​

目标：制定群体决策的方式。

当前团队：Zheug（主导）、unicornio

工作汇报：

• 已创建发起提案、提案投票及决策发布上链时需遵循的流程概要。
• 已创建一个 Coordinape 页面用来试验声誉的分配。
• 治理会议开始在每周二定期举行。

协议升级​

目标：增加协议用途，消除金库管理流程的摩擦成本。

当前团队：Jango（主导）、Exekias、Peri、Nicholas

工作汇报：

• TerminalV2 合约开发进展顺利。这一升级将允许项目全面定制自己的金库策略。细节待定，点击这里查看具体实现和正在做的测试。
• TerminalV2 将可以修正最近发现的一个边缘案例的 bug，具体请见前面的 “降低风险”。

我对于第四周期的提议：​

周期时长： 14 天（不变）

选票合约： 3 天延迟（原 7 天） 重新配置的请示必须在当前筹款周期结束前3天之前提交。原来提前 7 天感觉重新配置的决定时间有些仓促。把选票延迟从 7 天调整为 3 天让我们能有更多时间来评估提案及把变化发布上链。

折扣率： 10% 折扣率应该继续以 10% 的比例复合增长，以奖励那些在这个风险阶段继续向 JuiceboxDAO 金库捐款的人。

联合曲线： 60% (+-0%) 这项无需更改。这个数值仍然是随意的，但由于目前没有赎回的需求，所以我们在调整折扣率的同时，不妨把这个值保持在偏紧的水平。

支出： 共 $33.5k 我建议我们给 exekias、 nicholas、 nati 和 buradorii 支付稍多一些。

核心贡献者

• jango | 开发 : $10k (没有变化)
• peripheralist | 开发 : $10k (没有变化)
• CanuDAO | 沟通：$2.5k（没有变化）
• WAGMI Studios | 艺术、动画和教育内容：$2.5k（没有变化）
• exekias | 开发: $4k (+ $1k) Exekias 对代码的所有方面都亲力亲为。越来越成为核心开发人员不可或缺的一员。

实验性贡献者

• nicholas | *开发: 2千美元 (+ 500美元) * nicholas 已开始着手编写代码，他一直是我们社区中的一个活跃分子，帮助推动一些关键的讨论。
• Nati | 社区关系：1千美元 (+500美元) Nati 已开始引导一些 DAO 加入 Juicebox，同时也帮助推动一些关键的讨论。
• Buradorii | 分析：1千美元（+500美元） Buradorii 已开始发布一些 Flipside 的数据面板。我们还需要整合图表及提供给项目。

拨款

• Figma、Infura、 Gitbook、 Mee6 及 Fleek 的订阅费用 | 500美元

保留率： 35% (没有变化) 我们应继续分配 25% 给核心贡献者，同时保留 10% 用于奖励为 ETH/JBX 提供流动性的人（很快）。

保留的代币分配：

• jango： 35%
• peripheralist： 35%
• CanuDAO： 10%
• WAGMI Studios： 10%
• exekias： 7.5%
• 其他杂项： 2.5% - 用于多签钱包支付的灵活奖励。

SharkDAO, 使用 Juicebox 协议发展最快同时也最有望突破的一个项目，目前需要为其 Juicebox 金库代币创建 AMM 流动池以实现持币人价格的有机发现。大部分上了规模的 Juicebox 项目将来都会有这个需求。

SHARK 代币的价值不仅来源于存放在 Juicebox 合约里的 ETH，来源于 DAO 动用金库资金获得的那些 NFT，来源于 DAO 在支付平台费用的同时积累的 JBX 代币，可能最重要的是来源于项目里凝聚的极富创造力社区将带来的无限潜能。以上每一项资产的预期价值都是动态的，取决于每个个体的信心和风险偏好。这就需要一个比 Juicebox 协议更为灵活的做市机制和订单配对策略。

Juicebox 给 SHARK 代币的持有人一个有效筹款及扩张的途径，但没有给他们提供一个协调既有价值的办法，那是 AMM 的长处。SharkDAO 在未来很长的时间都会需要以上这两个功能。如果 Juicebox 希望成为初创项目规模化后的首选金库协议工具，它不仅需要理解现有机制加上代币流动池时的表现，还必须弄清楚进行哪些协议调整才能逐步弥补所有已知的市场缺陷。

当前的局限​

目前 Juicebox 项目的金库不能配置最高代币供应量。协议一直向人们提供捐赠 ETH 并按当前筹款周期权重相应地获得金库代币的机会，这个权重是由折扣率的复合效应及当前配置的保留率共同决定的。

提醒一下，折扣率会在筹款周期更替之后降低每捐赠一个 ETH 铸造的代币数量，当前筹款周期 10% 的折扣率意味着下一周期捐赠 X 个 ETH 获得的代币数量将是当前周期捐赠同样数额 ETH 可获得代币数的 90%。而保留率则决定将会保留多少代币用于分配给预设的接收地址。

因此协议其实一直为某个项目代币进行定价，让他们主动增加代币供应量来满足需求，来换取筹集更多的 ETH。所以期望 AMM 上金库代币的市场价格超过协议的报价是不现实的，协议的报价一直会是代币价格的天花板。倘若二级市场价格高于协议价，就会出现明显的套利机会把价格拉回来。

但是会有一些人，他们过去用较低成本获得了金库代币，现在愿意以低于协议价卖出获利。随着筹款周期的发展及折扣率的复合作用，这一供应端的压力就会有机产生。至于需求端，人们寻求在二级市场获得比协议内更优惠的代币价格也是情理中事。如果绝大多数的交易活动发生在低于协议价格的二级市场，那么代币供应和资金募集将会在这个供需平衡慢慢减少。

项目怎样去选择获得这个平衡就成了一个大问题。是应该按自己的公平原则逐渐微调折扣率和保留率，把二级市场用于方便买卖双方交易，但同时限制其自然发现价格上限的潜力？还是应该把二级市场作为主要的公平指标，折扣率和保留率仅用于满足筹款需要？答案往往取决于社区的价值观。社区是否要在优先考虑现金流的同时做到自由开放、包容并蓄、进退有据？还是严格保护当前成员辛苦积攒的价值，将来的战略性募集或扩张仅限于增值的动机？再或者选择两者之间的平衡，以既定原则来指导决策？

对于希望扩张供应量来吸纳新资金和新社区成员的项目来说，Juicebox 的工具组合确实发挥了良好的作用。但有些项目期望保护既有价值并逐步组织更具战略性、目的更明确的筹款活动，复合折扣率和保留率这些机制在目前协议的框架之内不一定能起到非常好效果。

解决方案​

解决方案可能很简单。

Juicebox 协议想要支持市场化驱动的项目，必须允许他们：

• 明确项目金库代币的供应上限，以及
• 允许项目自行决定每收到一个 ETH 要分发的金库代币数量。

在这些条件下，如果项目金库收到付款的时候代币供应量已经达到上限，就不会再相应铸造新的代币。否则的话，如果项目设置好一个预定的金库代币价格点，则会按这个价格来铸造新代币，不再按照之前周期的折扣率复合计算得到的当前筹款周期的权重。

这些工具允许项目本质上“暂停”发行新的金库代币，以及在任何时间节点以具体的价格开放供应一个定量的新代币。既有的保留率可以在这个模式下把新发行代币转到一些有时间限制的分配机制、质押激励池、项目的多签钱包等等。

加入这些参数确实会赋予项目更大的权力，这是一个需要引起注意的弊端。项目早期捐赠的人不能再确保他们的代币成本一定比未来周期的发行成本低，协议价格也可能会跟随项目方的意愿发生剧烈的变动。社区必须再三地确定他们项目的所有权（以一个 ERC-20 合约为凭据）由一个值得信赖的钱包来掌管，而且这个钱包愿意执行集体作出的各项决策。我对此并不太过担心，因为目前的实现在很大程度上已经是这个样子。

设置代币供应上限的另一个弊端是，这样会带来 DAO 与 DAO 及 匿名个人与 DAO 之间协同合作的一致性风险。举个例子，假设某人搭建了一个 NFT 市场，这个市场会自动把艺术品某个百分比的销售收入转到预先设置的接收地址，比方说 SharkDAO 的金库。如果 SharkDAO 设置了代币供应上限且已经到达这个上限，艺术品销售所得的 ETH 仍将转入项目金库，但艺术家却不能相应地获得任何 SHARK 代币。我同样不太担心这个弊端，因为在现行机制下，如果项目把保留率调至 100% 也会是同样的后果。每一个跟 Juicebox 项目合作的项目或艺术家应该始终明白，合作会存在变数 — 各种参数比率可能发生变化，因此优先与那些通过适当规则和社区参与来公开决策的可靠项目建立关系就显得尤为重要。

另一个要注意的细节：两个新参数的配置仅限于筹款周期配置才能进行调整 — 如果项目以固定时间的周期来运行，那么代币供应上限及权重覆盖参数的变更要等到新的周期开始才能生效。如果项目的筹款周期持续时间较长、重新配置投票制度更严苛，则项目的运营会更有可预见性，也会有更多的制衡。这样做可能还有一个后果，如果带供应上限的新周期配置交易已提交但尚未生效，当前无供应上限的周期就已经铸造出来超过这个上限的代币数量，就会出现实际代币供应量比配置的供应上限要高的情况。

我们正在草拟一个提案，准备把这两个新的属性实现到 Juicebox 生态内的 TerminalV2 合约里去。V2 合约部署并得到 DAO 的批准之后，目前在 TerminalV1 运行的项目将可以选择是否迁移过去。

加入 JuiceboxDAO 的 Discord 来参与这个讨论，在我们把这些附加项加入协议之前，提出你的观点和看法。