JuiceboxV2 协议

2021年9月3日 · 15 分钟阅读

JuiceboxDAO Contributor

现状

首先：非常感谢过去一个月来使用过第一版 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。

现状​

提议的变更​

自带铸造/销毁策略​

溢出容差​

开放铸造/销毁​

保留代币的分配目标​

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

可调整的费用​

结论​

现状