Comprehensive analysis of PANVALA: a decentralized Ethereum funding platform
DAOrayaki DAO Research Grant：
Fund Address: DAOrayaki.eth
Voting Result：DAO Committee Yes
Grant Amount：200 USDC
Category: DAO, PANVALA, Dontations, Grants, Decentralized Ethereum Funding Platform, Slate Governance
Contributor：Jones @Daorayaki, 黑白QB @Daorayaki
创立时间：2017年7月
代币名称：PAN
代币类型：ERC20
一、介绍
panvala是一个去中心化的以太坊基金系统。该系统通过资助（grants）和捐赠（donations）模式，持续的资助公共物品（以太坊整个生态系统所依赖的基础设施和应用程序）并不断的改进他们。Panvala被视为是一个自组织运转并提供非竞争性商品的系统。
该项目成立的背景和原因如下：
最初的创新项目是基于比特币的分叉，并在比特币链的早期历史中通过挖矿获得奖励。后来的项目有了自己的代码库，并经常 "预挖 "代币，为自己保留或出售给他们的资助者。以太坊也举行了第一次众筹活动，为创建新货币募集资金。以太坊引领了使用此类融资模式项目的爆炸性成长。目前，这种方式已经被大多数项目采用。然而，以太坊也受到了这种模式的限制。
当年，许多人致力于维护和建设以太坊网络，因为改善者认为，持有的以太币会随着网络的改善而变得更加有用。从首次发行代币到现在。代币价格已经上涨了1000多倍。这种动力已经开始变弱。任何团队都很难感受到他们的工作对以以太坊或者以太币的任何影响，但对社区的影响却非常显著。詹姆斯-普雷斯蒂奇（James Prestwich）曾观察到，"以太坊不为人知的弱点之一是它无法长期保留人才和经验"。之后，在2018年12月，致力于实现以太坊2.0的工程师Preston Van Loon在Twitter上发表了他的担忧，"我们[在Prysmatic实验室]注意力被分散，我们仍然需要完成其他工作。即使最近有下发grants，也不能让我们将团队的规模扩大到我们需要的程度。" 作为回应，维塔利克-布特林(Vitalik Buterin)在推特上说："刚发了1000个eth。Yolo！"。尽管这是值得赞赏的，但此类 捐赠模式也表明，以太坊社区中缺乏提供公共物品的机构。
但是，除了资金不稳定外，竞争的威胁已经隐隐出以太坊的社区中。我们一直都知道，以太坊需要改变规模以适应对智能合约的需求，并不是只有以太坊的忠实拥护者能够实现此类需求。当面对与以太坊合作还是竞争的选择时，许多技术的团队都会选择竞争。如果启动自己的区块链，奖励贡献者和投资者要更容易–你可以向任何人发行新代币。如果是改善以太坊，如何奖励您的团队？
Panvala的成立就是为了解决这一问题。与以太坊社区合作比与之竞争更具回报。为此，panvala构建了一个去中心化的以太坊基金会系统，该系统以自己的代币运行。另一方面，以太坊基金会多年来经常受到批评，因为以太坊基金会未能实现其目标。因此，Panvala是为以太坊基金会成功实现其目标而创建的。此外，以太坊基金会剩余的600,000 ETH不可能永久持有，它打算在明年花费约3000万美元，做到与竞争对象资助水平大致相同，即使这些被资助的项目甚至没有启动。这就是为什么我们需要Panvala的能力来筹集新资金并充当去中心化以太坊基金会。
更抽象地讲，Panvala是一个自组织运转并提供非竞争性商品的系统。非竞争性商品可以非常便宜地提供给使用的人，例如电解决影院的容量不足或有新的研究发现问题。作为比较，让我们来对比难以共享的私人物品的例子。例如手机或牙刷。每个人都为自己负担得起的私人物品付款。在政府法规的帮助下，市场会自组织此类商品的供应，这也就是为什么私人物品，更便宜，更高效。但是对于可以共享的非竞争性商品，Panvala会为它负担得起的商品付费。它会自行提供公共物品，并不断改进它们，以赢得并维持捐赠者的忠诚度。
二、运转模型
赠款（grants）:
Panvala grant 将发放给那些致力于实现以太坊愿景的团队，主要用于开发整个生态系统所依赖的基础设施和应用程序。grant通过Panvala代币发放。
此类资助，可以从项目开始的第一天发放。在有人想要购买此类项目的代币之前，因为较早期，资助无法定价。所以，这些代币的买家，是那些想要资助生态系统发展的捐赠者。
Panvala关于grant发放具有以下三个条件：
- 代币的固定供应量为1亿个。
- grant代币的发放速度受代币容器（token capacitor）的限制。
- 代币持有人必须使用推举提名治理（slate governance）来管理grant的发行。
除了这三个限制外，代币持有人可以自由地安排他们对所发放代币的支出。由于我们社区的大多数非股权融资项目都是采用grant的方式运作，所以我们默认采用这种模式。此外，该系统也适用于预算模式，即团队可以收到持续资金来执行一项持续的功能，另外，还可以以项目为基础，对寻求各种资金来源的团队进行资助。
捐赠（Donations:）
Panvala旨在向社区希望支持的工作提供资金流。Panvala的grant是发放给单个团队的，但捐款（donation）是面向整个系统的，而不是面向单个项目。这些捐款是基于Panvala代币进行的。Panvala的代币可以使用更多流动性更强的货币（例如美元，KRW和ETH）来获取，但Panvala除了自己的代币外，无法持有其他任何货币。
捐赠者从贡献者团队那里购买代币（直接从团队那里购买，或通过交易所间接购买），然后将这些代币转捐回Panvala系统。这就完成了这个循环，也使的Panvala可持续发展。此外，从获得资助的团队购买代币是必要的，但不足以进行捐赠。一个出售代币的团队现在有能力来负担项目运转，而代币的购买者将有三个选择：将代币捐回系统；无限期地持有代币并对Panvala的决策进行投票；持有代币以便将来售出。当捐赠者购买转售的代币时，他们的花费并不会资助任何工作。
这就是为什么从一个团队购买代币将不被视为捐赠。当您将获得的代币存回系统中且无法转售时，才会视作捐赠。同时，Panvala社区认可进行捐赠的个人和企业，以鼓励更多的人加入。捐助Panvala的企业会根据其捐助计划所需的年度承诺，赢得社区的感谢和关注。Panvala的个人捐助者根据他们承诺的持续性捐款数额得到认可。Panvala的优势是由代币持有者，grant接受者和整个Panvala社区获得的，而不是由Panvala启动团队获得的。
三、团队成员
自2017年7月以来，Panvala创始团队一直在ConsenSys开发Panvala。该团队由Niran Babalola，Romana Basilaris，Daniel Schifano，Jacob Cantele，Akua Nti和Isaac Kang组成。
- Niran Babalola 项目创始人
Meta_Cartel成员，经济学家，表演艺术家，之前曾任ConsenSys产品工程师，TabbedOut产品经理和高级软件工程师。
联系方式
LinkedIn: https://www.linkedin.com/in/niranbabalola
Twitter: https://twitter.com/niran
Github: https://github.com/niran
2. Isaac Kang
以“kangarang”著称，软件工程师，热衷于开发改变世界的软件产品。目前在Consensys和Treum担任软件开发人员。
联系方式:
LinkedIn: https://www.linkedin.com/in/isaackang
Twitter: https://twitter.com/_kangarang
Github: https://github.com/kangarang
3. Jacob Cantele
曾任最大的在线高端房地产中介Concierge Auctions的首席技术官，他是一个创新者和技术专家，在网络应用和软件工程、精益创业方法论等方面具有丰富的经验。
联系方式:
LinkedIn: https://www.linkedin.com/in/jacob-cantele202286a5
Twitter: https://twitter.com/jacobcantele?lang=en
Github: https://github.com/jacobcantele
4. Daniel Schifano
他热衷于设计创新、吸引人的产品，为用户提供商业价值和良好的体验，曾在ConsenSys担任产品设计负责人，在Rangle.io担任高级产品设计师和顾问。
联系方式:
LinkedIn: https://www.linkedin.com/in/daniel-schifano/
Twitter: https://twitter.com/danielschifano?lang=en
Github: https://github.com/danielschifano
5. Akua Nti
ConsenSys的协议工程师，是panvala启动团队的一员。
联系方式:
LinkedIn: https://www.linkedin.com/in/akuanti
Github: https://github.com/akuanti
四、Panvala治理机制
- 候选集治理（Slate Governance）
Panvala在每个季度使用提候选集治理（Slate Governance）机制进行决策，系统会批准一系列候选行动和它所包含的所有个人提案。此外，不认同Slate 能够代表社区共识的pan持有者可以提出竞争性的Slate 。此外，必须在每个提议上押注pan，而押注失败的代币将被捐回给代币容器。
每个slate都与编写该Slate 的推荐者相关。尽管大多数链上决策系统都涉及批准或拒绝单个提案，但需要回答的主要问题是“应使用哪种决策程序”？Slate 的推荐者始终代表着特定的决策过程，即使界定不明确也是如此。如果做得好，推荐人将清楚地制定决策过程，而推荐的Slate 则代表了该过程的结果。一些示例包括链下投票，选举代表机构或依靠信誉良好的权威。从另一点来看，对个别提案的质疑是在推荐者已经界定好的过程中完成的，对个别提案的质疑就像修改宪法：当规则不再符合社区目标时，您就可以更改规则，但这不是因为您不满意一个特定的结果。
2. 设计目标 （Design Goals）
候选集治理（Slate Governance）旨在避免在去中心化系统中常见的缺陷。到目前为止，已部署的系统通常会看到大量决策，但是投票率低的信号已表明，基于代币的投票可能实际上并未奖励评估决策所付出的努力。从其他系统也看到了收费决策:比特币多年来一直以拒绝改变而闻名，不管是好是坏。panvala团队将这种惰性视为比特币基于分叉治理规则的意外结果。为抵制变革辩护的原则是对一种突发现象的事后合理化。
基于分叉的治理也已经进入了链上系统。TheDAO是一个基于分叉的组织，其中代币持有人可以在他们不想合作后，分叉出一个新的组织。(TheDAO在我们看到其设计是否可行之前就被黑掉了)Moloch DAO以其 “怒退”的机制追随TheDAO的脚步：在每次批准后的等待期间，如果他们不想支持该提案，任何人都可以撤回他们剩余的eth。这些设计使人们很容易决定加入。但因为没有真正的承诺，机制的潜力也受到了限制。Panvala避免了基于分叉的治理，其目标是建立一个承诺的社区，即使在成员没有得到想要的方式时也依然会合作。
谈到链上投票，panvala团队认为这种投票追踪记录很差，应该作为一种最后的机制，而不是在系统的正常运作中使用。他们的方法与Plasma类似，Plasma是一种区块链扩展策略，它建立了可以通过根合约（root contract）进入和退出的子链。当Plasma子链正常运行时，很少有交易被送出链外。当出现问题时，这可能会触发数以千计的交易到区块链上的根合约，以便人们可以移除资产。类似地，当一切在Panvala中正常运行时，很少有治理交易被发送。在冲突或攻击期间，可以触发成千上万的交易来统计投票以解决问题。
3. 资源和权限 （Resources and Permissions）
许多链上治理的设计都是围绕批准共享账户发送的交易，从而使代币持有者可以集体执行与个人执行相同的操作来发送交易。传统的多签名钱包是这种设计的最简单体现，而Aragon DAO是复杂的、基于代币的设计，它控制发送任意交易的单个Aragon Agent。Panvala避免了这种设计，主要是为了避免成为一个共享的资产池。由于Panvala不能发送交易，它不能持有除其自身代币以外的任何资产。Panvala的资源不发送任意交易，而是允许任何人请求与它们互动的权限。资源是任何定义权限的智能合约（如代币容器），然后将其送入把关人（gatekeeper）进行审批。把关人合约是代币持有者创建权限提案slate的地方，如果有必要，还可以对它们进行投票。把关人的资源、调用的两个权限功能。
资源存储从请求Permission 返回的权限标识符以及关于每个权限请求的账本信息，以便它们能够检查权限是否已被授予，确保一次性使用的权限尚未被使用，并执行所需的行动。例如，token capacitor为每个提取token的请求存储Proposal结构。
追踪每个提案所使用的审核实例，对确保治理合约的升级顺利尤为重要。
4. 候选集 slates：
一个slates包含对单一资源的零个或多个许可请求。slates是由推荐人撰写，推荐人可以选择是否在他们的slates上押注，以将其加入到竞赛中。如果推荐者未在此名单上投注，则其他人必须在此押注，否则该名单将被忽略。每个资源都有自己的一套slates，每季度竞争批准权限。因此，每个资源每个季度都有一项独立的竞赛。一些资源可能在同一季度触发投票，而其他资源则没有竞赛。同时，如果一个资源在一个季度内只有一项押注的slates，该slates自动获胜，其权限被批准，而提交的slate没有任何要批准的权限请求，被称为空白slates，当代币持有者的共识是对该季度不采取行动时，这些空白slates就可以被推荐。
5. 现任职权（Incumbency）
推荐者代表了在链外达成共识的过程，即批准哪些权限。Panvala强调了推荐人的身份，将链上决策的重点从slate上的许可优势转移到这些许可被添加到slate的过程。一项资源的最后一个成功推荐者是该资源的责任人。责任人实际上是目前有效章程（bylaws）的体现。如果责任人的推举的slate在竞争中失败，被拒绝的不仅仅是他们的提案，还有他们所代表的隐含章程（bylaws）也将被拒绝。希望它们能被更好的章程所取代。作为一个特例，如果一个季度内没有人提交提案，那么最后的责任人就会持续存在。"在位不能空缺"。
6. 投票（voting）
Panvala使用一个提交-披露程序来统计投票。在提交阶段，投票者提交其投票的哈希值，同时对投票本身和随机salt进行保密。在披露阶段，不能做出新的承诺，而先前的承诺可以被披露。这类似于典型的选举经验，即在投票站关闭之前，无法对获得票数进行统计。
每个代币可以获得一张选票。为了获得投票权，代币必须在提交阶段之前或期间存入把关人（gatekeeper）合约，且在提交阶段结束之前不能撤回。这可以防止同一代币被用来获得多张投票。投票者可以将他们的投票委托给另一个以太坊账户。这使投票者可以安全地存储控制其代币的密钥，同时委派给无法提取代币的常用密钥。作为默认操作，如果正在进行一场竞赛但没有人投票，则该资源的所有slates都将被拒绝。
7. 排名选择和决选（Ranked Choices and Runoffs）
当比赛有两个竞争候选名单（slates）时，获得更多选票的slates将获胜。但是，当比赛有三个或三个以上的竞争slates时，选民可以表明他们对提名者的第一和第二选择。如果有任何slates获得超过半数的优先选择票，则该slates获胜。否则，除了前两名slates外的所有slates都将被淘汰。对于第一选择被淘汰的选民来说，任何对前两名slates的第二选择票都将被计算在内。其余得票最多的slates获胜。以下面的示范为例。
8. 纪元 （Epochs）
每个治理期被称为一个纪元，持续十三个星期。零纪元从2018年11月2日17点（UTC）开始，到2019年2月1日发放第一批grants时结束。
一个纪元内的第一个截止日期是提交slates的截止日期。在这个截止日期之后，就不能再为给定的资源押注或推荐。slates提交的硬性截止日期是一个纪元的11周，但为了防止slates在最后一刻被偷袭，软性截止日期从纪元的5.5周开始，并随着slates的提交进行调整。每次为某一资源设定slates时，软期限被重置为当前时间和硬期限之间的一半，这使得软期限随着每次推举提名提交而接近硬期限。因此，每个资源可以有一个不同的软期限来提交推举提名。在第11周结束时，投票承诺期开始，持续一周。在第12周结束时，投票披露期开始，持续一周。一旦纪元结束，就不能再透露更多的投票，因此可以最终确定竞赛，并批准获胜名单的权限。每个许可申请在下一个纪元结束时失效。
9. 参数储存 （The Parameter Store）
参数存储持有受Panvala治理程序约束的键值对（key-value pairs）。参数存储为我们提供了一个通用的API来提出、批准和执行对参数的修改，而不是需要调用不同的函数来改变不同的参数。这种模式的灵感来自于原始代币存储的注册表（token-curistry）实现中的参数器（Parameterizer ）合约。
10. 初始参数 （Initial Parameters）
参数名称 Parameter Name | 参数类型Paramater Type | 说明 Description | 值 value |
|
| ||
|
| ||
|
11. 可升级性 （Upgradeability）
虽然代币容器（token capacitor）和参数存储合约不能改变，但把关人（gatekeeper）合约被设计成可以随着时间的推移而升级。与OpenZeppelin和Aragon流行的可升级合约模式相比，Panvala团队使用的是Peter Borah和Colony团队流行的较早的 "EternalDB "模式，即在代码改变时，合约保持其地址和存储。在后一种模式中，状态与代码分开存储，控制访问状态代码的地址随着每次升级而改变。这个 "EternalDB "就是参数存储。参数存储不是有一个可修改的所有者将授权的变化推入合约，而是从把关人合约中拉出变化，把关人合约也是由一个参数指定的。只要新的把关人合约遵循原合约的权限API，新版本就可以实现任何需要的决策逻辑。
更新把关人将所有相关的合约从旧的把关人那里指向新的把关人。由于改变把关人的纪元也可能包含许多其他的决定，社区采取的升级方式有很大的潜在影响。只要资源在每个把关人旁边存储动态审核的地址，以确保权限查找不会被把关人升级所误导，那么权限在过渡期间就会像预期的那样运作。除此之外，代币余额和授权可以由个人投票者转移，但必须注意通知投票者有足够的时间来准备过渡。责任人更难转移：因为新的把关人必须在被授予升级权限之前部署，新的把关人不会知道那个时代的责任人，除非它被写成能够获取它们。在这种情况下，当涉及到状态转换时，把关人升级有三种选择：他们可以做一个失去责任人数据的干净的中断，他们可以在新把关人的初始化函数中获取在位数据和任何他们想要转换的东西，或者他们可以使用Merkle证明或使用更新合约内代码的升级性模式的新把关人合约来保留所有状态。如果没有其他已知的合约在使用现有的数据，干净的中断升级应该没有问题，但第三方合约可能已经开始依赖该数据而没有通知你。获取所需的状态进行转换可以避免破坏依赖责任人数据的已知或未知合约。
12. 治理示范（Governance Demonstrations）
slates治理的第一个示范是由Panvala Mark理事会进行的，该理事会是由以太坊社区成员组成的小组，为此目的而任命。2018年10月25日，Panvala Mark理事会召开会议，建议为一个简单的多签名钱包智能合约发布一个Panvala Mark。
13. 错误恢复（Error Recovery）
智能合约是僵化的程序，在部署后很难修改，而且风险很大。其他应用程序中的许多合同都有bug和安全缺陷。虽然团队采取了最佳实践的预防措施来避免这些问题，但仍有可能出现我们没有预见的问题。在出现严重错误的情况下，代币容器的现任责任人应该提出错误恢复的建议。在某些情况下，可能很容易部署固定版本的合约，用一个新的代币来复制错误发生时的余额。更复杂的错误可能更难恢复。由于Panvala只持有自己的代币，所有的错误都可以通过系统的一个新实例来恢复。确定该新实例的初始状态是困难的部分，代币容器的现任责任人应该引导社区达成共识。
五、Panvala激励机制
- Panvala代币
系统的代币是pan。在指定pan的数额时，在数额前使用?符号。例如，?5000可能需要押注在一个slates上，而一批grants可能有?200万可用。"PAN "在交易所交易时或在任何其他需要使用的情况下，与美元、韩元和ETH一起用来代表Panvala的代币。当需要代币的全称时（如 "美元 "或 "韩元"），代币就是Panvala pan。Pan既是单数也是复数。Panvala不是通过众筹资金并将其用于贡献者来协调捐赠，而是通过向贡献者发放自己的代币grants来协调捐赠。捐赠者购买这些代币并将其捐回代币容器。没有办法直接向Panvala捐赠美元、韩元或以太币。这些货币被用来从贡献者那里获得pan，并将其捐回系统。
2. 代币目的
（1）产权（Property Rights）
使用产权来组织合作，使人们很容易做工作并得到奖励，而不需要任何人的批准来这样做。因此，有能力改善财产的人可以确定自己的身份，而不需要得到中央规划者的认可。一个正常的基金会雇用捐赠者发展成员，以增加进入该组织的捐赠流量。Panvala不需要有少数几个因增加捐款而得到奖励的捐助者来发展，而是可以挖掘成千上万甚至数百万的代币持有人，他们都可以因增加对生态系统的捐款而得到奖励。对系统的捐赠越多，对所持有的代币的循环需求就越大。代币持有者有动力去利用他们的社交网络，招募更多的捐赠者，以资助我们都关心的工作。
（2）委托人和代理人的一致性（ Principal-Agent Alignment）
许多由捐赠者资助的组织是无效的。这些组织的管理层充当了捐赠者的代理人，捐赠者希望他们能最大限度地利用他们的捐赠做好事情。然而，由于他们的有效性很难衡量，而且往往是由少数几个大的捐赠者主观定义的，与有更明确影响衡量标准的营利性组织相比，该组织的管理层可能与他们的有效性的增减相去甚远。要解决委托-代理人问题，让代理人按照委托人的利益行事，是众所周知的困难。在Panvala，pan的持有人是Panvala捐助者的代理人。Pan让它的持有人在系统的未来中拥有利益。如果pan持有者投票有效地发放grants，他们就会增加向Panvala捐赠的数量和规模，从而增加对他们持有的pan的需求。如果他们发放grants的情况不好，捐款就会减少，对他们持有的pan的需求也会减少。因此，我们期望pan持有者对当前和潜在捐赠者的意愿作出非常积极的反应，尽管捐赠者本身在系统中没有投票权。
（3）辅助性 （Subsidiarity）
虽然每个代币对系统的所有行动都有影响，但它们也创造了一个辅助性的位置，允许决策被推到Panvala的较低层次。一些组织按地域或职能划分，但团队预计，划分Panvala的最有效方式是按押注的代币池划分。今天，Panvala的个人捐助者在系统的最高层得到认可，但在未来，最重要的可能是这些捐赠被分配到的押注池。然后，这些押注池可以根据其池中的代币数量和他们所组织的捐赠流量的大小进行评估和认可。
3. 账户单位 （Unit of Account）
捐赠是以Panvala的账户单位而不是以pan计算的。在启动时，Panvala的账户单位相当于1美元，虽然这是事实，但我们避免提及账户单位，而只是使用美元。然而，我们预计，随着时间的推移，Panvala的账户单位将被调整，以实现尽可能多的Panvala的全球社区的稳定价值。当这种情况发生时，账户单位将由代币持有人命名。
4. 首次分配 （Initial Distribution）
Panvala于2019年2月1日开始发行grants。此时，代币容器中持有5000万pan，其余5000万pan保留给Panvala启动团队分配。截至8月2日，第一、二、三批grants共发行了6,093,697pan，代币容器中还剩下43,906,303pan。在供Panvala启动团队分配的5000万pan中，该团队保留了2000万pan。ConsenSys持有500万pan，另外还有500万pan用于ConsenSys的项目，整个社区都可以使用，如MetaMask、Truffle和Burner Wallet。ConsenSys被分配了额外的600万pan，但选择将它们捐回给代币容器，用于未来的grants。(因此，代币容器将在链上初始化，余额为49,906,303pan。) 500,000pan将被存入Uniswap，这是捐赠者获取代币捐赠的默认方法。顾问们持有3,500,000pam。
启动合作伙伴持有剩余的1000万个pan。启动合作伙伴是第一批、第二批和第三批中选定的资助者，他们承诺在Panvala的前两年通过赚取或购买pan来进行捐赠。他们每个人都有每月的捐赠目标，必须达到这些代币才能被释放，可以提前三个月进行。如果他们落后超过一个月，分配给他们的剩余代币将被捐赠给代币容器。最后，所有的pan开始在那些为实现以太坊愿景而工作的人手中。除资助之外的所有pan都要进行归属（vest）：每从代币容器中释放一个pan，就有一个pan被归属。
5. 代币容器 （The Token Capacitor）
代币容器是一个智能合约，用于释放代币以获得grants，并接受代币作为捐赠。容器中的代币是以随时间推移呈指数级衰减的速度释放的。Panvala的代币容器被配置为1456天（四个52周）的半衰期，就像比特币的区块奖励衰减。这个半衰期参考了其他数字货币的做法，以及公司发行股票的常见做法。然而，这仍然只是一个猜测。我们硬编码这个值，并不是因为它肯定是永远正确的选择，而是因为我们认为，让它容易改变释放曲线会阻止人们的参与。从代币容器中提取代币需要通过推举治理程序获得许可。该过程有自己的授予权限的时间表，但代币容器本身并不强制限制提款的时间。它只是根据最后一次提款或捐赠后的余额、该变化的时间以及此后的时间来限制可以提取的代币的数量。
- 指数衰变 （Exponential Decay）
代币容器释放代币的速度，使其余额呈指数式衰减。理想情况下，这种衰变会遵循指数衰变的公式。
N(t)是新的余额，
是之前的余额。t 是上次释放代币后所经过的时间，
代币容器的半衰期，1456天。
然而，由于实现这个公式所需的浮点运算有确定性问题，所以它不太适合在区块链上执行，因为成千上万的节点需要就结果达成一致。以太坊虚拟机不包括浮点指令就是因为这个原因。这导致团队采用了两种有吸引力的方法来实现指数衰减：为选定的t值存储一个预先计算好的衰减因子值的查询表，或者创建一个释放率的时间表，用一个分片函数近似指数衰减。此外，验证一个特定的分片时间表的实现是否没有任何可能破坏系统供应政策的缺陷也比较容易。分片函数是确定的，而试图更接近曲线则取决于先前的平衡序列和从查询表中使用的乘数的行为。此外，由于这些智能合约的目标是在一个大社区内建立共识，所以在使用公众可以在头脑中进行的数学运算时，能够准确传达应该释放多少代币是非常有用的。比特币的区块奖励时间表也以这种方式近似于指数衰减。然而，Panvala的代币容器释放是基于当前的余额，而不是像比特币那样基于当前的时间。比特币可以从时钟上读取，以确定发生了多少次减半，但Panvala将不得不为每个释放率存储或计算余额界定边界。通过捐赠，余额可能会出现不可预测的波动，任何分片时间表的实现都必须考虑到跨越时间表边界的释放。总之，这些问题增加了实施的复杂性，接受查找表方法的缺陷是一种正确的权衡。
7. 创建查询表 （Creating the Lookup Table）
为了创建查值表，首先必须选择该表支持的最小时间间隔。间隔越小，截断的误差就越大，每次迭代都是如此。为了将这些乘法器用于整数，在使用乘法器之前要使用一个精度等级，然后在完成后除以精度系数。选择一天作为最小的间隔，1×10作为精度系数。它们共同产生了一个半生中50,000,000中约531个代币12的误差。该团队将查找表的其余部分填充为2的幂，以便能够在容器的平衡变化之间经过更多时间时保持更高的精度。然而，他们期望实现每天超过一次的捐赠流量，这将导致一天的乘法器被使用的频率远远高于其他任何一天。每次用乘法器进行乘法，任何现存的误差都会加重。因此，与使用更多天数的乘法器进行更少的乘法相比，反复地使用较少天数的乘法器释放的代币略多。
8. 锁定的和未锁定的代币 （Locked and Unlocked Tokens）
容器的总余额被分为锁定的代币和未锁定的代币。未锁定的代币是唯一可以提取的代币，而锁定的代币是唯一参与衰变计算的代币。每次容器收到或发送代币时，在调整到任何存入或提取代币的请求之前，代币会从锁定的余额移到未锁定的余额。如果解锁余额在存款后被更新，该新的捐款将被包括在需要衰减的代币余额中，就像这些代币从上次余额更新后就一直存在一样。如果在提款后更新解锁的余额，如果要提取的代币还没有解锁，提款可能会被错误地拒绝。
有一个独立的函数可以通过以下方法将适当数量的锁定代币转移到未锁定的余额中。
1.计算自代币最后一次被解锁以来已过去的天数。
2.如果经过的天数是奇数，将锁定的余额乘以最低的乘数。除以精确系数，以确定锁定余额中剩余的代币数量。
3.将之前和新的锁定代币总数之间的差额加到合约存储的未锁定代币余额中。
4.将经过的天数除以2，转移到下一个乘数，并重复步骤2-5，直到没有剩余的时间。这将需要log2（t）次迭代，在一次交易中最多可以释放4095天的代币。
5.将合约的总代币余额和解锁的代币余额之间的差额存储为新的锁定余额。
6.将经过的时间加到最后的解锁时间。
任何人都可以发送一个交易来解锁代币，并将最后的解锁时间提前一定的天数，该天数小于或等于自代币最后解锁以来的总时间。如果自代币最后一次解锁以来已经过去了4096天或更长时间，则需要进行多次交易以使合约达到最新状态。在处理捐赠或提款之前，该函数在同一交易中被调用，以尽量减少使容器状态保持最新所需的交易数量。此外，当被允许提取代币时，解锁的代币数量会被提取的金额减少。大于解锁代币数量的提现会恢复交易。而捐款则直接加到锁定的代币余额中。
9. 记录捐赠（Recording Donations）
捐赠与元数据一起被记录下来，以便让公众了解捐赠的背景。特别是，对于公众来说，了解捐赠者的意图和他们在捐赠时对市场的看法是很有价值的。ETH/USD的当前价格，PAN/ETH的当前价格，以美元计算的预期捐赠，以及捐赠者打算履行的承诺条款都是作为捐赠的元数据记录的有用背景。
10. 捐赠策略 （Donation Strategies）
代币容器以一种新的方式协调捐赠，由于以前没有人做过，所以很难推理。Panvala团队想出了一个期望发挥效力的假设。
大量的、一次性的捐赠对长期的捐赠流没有影响，所以从长远来看，它们不会增加系统资助工作的能力。这与作为个人直接资助工作没有多大区别，但Panvala的目标是建立一个团队可以依靠的资金流。另一方面，对经常性捐款的长期承诺可以在很长一段时间内改变捐款的流向，这使得更多的工作可以使用较少的代币得到回报。期待Panvala收到稳定的捐赠流的团队可以稳定他们对代币资助的预期，这使得他们可以提前计划为以太坊生态系统做工作，而不是寻找私人公司来雇用他们。
作为长期代币持有者的捐赠者面临着一个选择：他们应该购买新的代币来捐赠，还是应该用他们已经持有的代币来捐赠？虽然这两种选择都是有效的捐赠，但通过减少长期持有的Panvala代币进行捐赠会产生反直觉的效果。下一批grants的购买力取决于获得的代币流量，而不是代币容器中的代币余额。
将代币添加到代币容器中但不涉及新获得的代币的捐赠对系统的购买力没有影响：每个季度释放的代币只是分配了从贡献者和代币买家流入系统的价值。如果获取代币的价值流保持不变，赠予代币的增加将伴随着代币价格的下降。为了对捐赠者的捐赠产生最大的影响 ，将其视为来自他们的收入而不是他们的持有量。在获得代币后立即捐赠，无论捐赠者是直接通过工作赚取代币，还是从别人那里购买。为了对他们持有的代币产生影响，他们应该无限期地持有这些代币，并利用他们的投票权来引导系统的发展。
理想情况下，以两种方式产生影响：持有代币进行投票，同时从收入中进行定期捐赠，对Panvala资助参与者喜欢的工作产生最大的积极影响。
11. PAN代币经济学 （PAN Token Economics）
Panvala的配套资金不是来自基金会或富有的赞助者。参与Panvala允许社区创建他们自己的匹配资金。Panvala的经济学是以比特币为模型的，它使用通货膨胀的区块奖励来为网络提供资金。当参与者持有他/她的BTC时，他们选择进入一个系统，他们知道他们持有的BTC将被稀释到2100万BTC的最大供应量，以资助矿工的区块奖励。同样，Panvala的投币者也选择了一个系统，他们将被稀释到1亿PAN的最大供应量，Panvala联盟的社区自己分配这种膨胀。
12. 净通货膨胀（Net Inflation）
与比特币模型的一个关键区别是，在Panvala中，所有的捐赠都回到了衰落的供应中。这意味着供应曲线并不预测未来的实际流通供应，而是预测最大的供应。在现实中，每一次捐赠都会减少实际流通的供给。
上图中的模型在每年100万pan左右的预算时达到平衡，可以无限期地维持下去。从长远来看，捐赠的流动给循环供应带来了向下的压力，这种压力根据经济条件而波动。这些波动是PAN价值变化的结果，也是捐款流量变化的结果。
批次Batch | 捐赠结束End of Donations | 价格PAN Price | 捐赠数量PAN Donated | 捐赠价值Value Donated | 捐赠倍数Multiplier | 最大通货膨胀率Max Inflation | 净通货膨胀率Net Inflation | 净通货膨胀率% Net Inflation % |
为了了解这些波动的情况，考虑一下过去几个季度的通货膨胀情况。PAN的价值在每个季度都在增加，但在7月3日和10月10日之间，PAN的价格增长超过了捐赠价值的增长。因此，尽管这些捐赠的美元价值增加了，但捐赠的PAN数量却从355,105降至158,206。Panvala的智能合约所允许的最大通货膨胀率每季度都会下降，但由于捐赠的PAN被从流通的供应中移除，净通货膨胀率在这两个季度之间实际上是增加的。
13. 终局 （Endgame）
一旦流通供应在十年或二十年后达到平衡，就没有通货膨胀的补贴了：每一个代币作为捐赠进入代币供应，就有一个代币作为通货膨胀出来。这与比特币网络的最终目标类似，即只依靠交易费而不是区块奖励。
随着时间的推移，Panvala将接近其最大供应量，通货膨胀补贴将减少。Panvala团队的假设是，在通胀补贴逐渐减少之前，他们可能有一二十年的健康通胀补贴。这就是为什么Panvala不只是追求社区的通货膨胀补贴：他们追求所有可能的社区补贴。随着通货膨胀补贴的逐渐减少，他们的目标是建立企业赞助，以保持资金流向Panvala联盟社区。这就是Panvala成为社区共享的可持续金库的原因：我们的方法可以使补贴永久地流下去。因此，参与者持有的PAN份额就是他们社区能够永久享受的Panvala补贴份额。如果BTC是数字黄金，ETH是数字石油，PAN就是社区的数字捐赠。
六、合约地址
Contract | Mainnet Adress | Filename |
七、社交媒体合集
社交媒体:
Twitter: https://twitter.com/PanvalaHQ
Discord: https://discord.gg/TBpv2R72
Medium: https://medium.com/@Panvala
Github: https://github.com/Panvala/panvala
Block explorer: https://etherscan.io/token/0xD56daC73A4d6766464b38ec6D91eB45Ce7457c44
Comprehensive analysis of PANVALA: a decentralized Ethereum funding platform
DAOrayaki DAO Research Grant：
Fund Address: 0xCd7da526f5C943126fa9E6f63b7774fA89E88d71
Voting Result：DAO Committee Yes
Grant Amount：100 USDC
Category: DAO, PANVALA, Dontations, Grants, Decentralized Ethereum Funding Platform, Slate Governance
Contributor：Jones @Daorayaki, 黑白QB @Daorayaki
Founded: The PANVALA project was founded and built in July 1017.
Financing:
PANVALA current price: $0,15USD
PANVALA current volume: As far as we know there is no information concerns the panvala initial volume or the current volume.
Token name: The panvala token launched out under the name PAN.
Token type: PAN token issued under the standard protocol ERC20.
I Introduction
Panvala is a decentralized Ethereum funding system. The system uses grants and donations models to continuously fund public goods (the infrastructure and applications on which the entire Ethereum ecosystem depends) and constantly improve them. Panvala is considered to be a self-organizing system that provides non-competitive goods.
The background and reasons for the establishment of the project are as follows:
No one knows who funded the creation of Bitcoin, but for every project that has stood on its shoulders, the path to take has become clear. The earliest new projects were trivial forks on Bitcoin, and were rewarded by mining early in the chain’s history. Later projects wrote their own codebases, and often “pre-mined” tokens to keep for themselves or sell to their funders. Ethereum itself held on of the first crowdsales to fund the creation of a new currency. By providing the ability to execute arbitrary smart contracts Ethereum led an explosion of new token systems that used the same funding model, and various system that started this way now seem on a credible path towards user adoption. Ethereum, however, has run into the limits of this model. While it’s a very effective strategy for launching new systems, holding these systems is still difficult.
Back then, many people worked on improving and building on top of the network because they felt that the Ether they held would become more useful as the network improved. Since Then, the price has increased over 1000x, and that incentive has become less perceptible. At this point, it’s hard for any single team to feel like their work has any bearing on the demand for Ether, and the effects on the community have been significant. James Prestwich, the founder of a company that enables cross-chain transactions, has observed that “one of Ethereum’s poorly understood weaknesses is its inability to retain talent and experience over time”. After that, on Dec, 2018, Preston Van Loon, an engineer working on implementing Ethereum 2.0, aired his concerns on Twitter. “Our biggest distraction [at Prysmatic Labs] is that we are still working full time for other jobs. Even with recent grants, it’s hardly enough to take the whole team full time with significant pay cuts and it’s certainly not even for us to scale the team to where we need it.” In response, Vitalik Buterin tweeted “Just sent 1000 eth. Yolo.” While the contribution was appreciated, this “YOLO grant” of ether has become the clearest illustration of the absence of institutions in our community to provision public goods. If our roads were paved or our updates on each flu season were funded by one-off grants from individuals, we’d be rightly terrified.
But beyond the risks posed by uncertain development funding, the threat of competition has loomed over our community for years. We’ve always known that Ethereum needed changes for scaling to accommodate the demand for smart contracts, and Ethereum loyalists haven’t been the only people with good ideas about how to do that. When faced with the choice of whether to cooperate with Ethereum or to compete with it, many teams with good ideas choose to compete. It’s far easier to reward workers and investors if you start your own blockchain—you can issue new tokens to whoever you want. If you improve Ethereum, how do you reward your team?
Panvala was founded to solve such a problem. By making it more rewarding to cooperate with the Ethereum community than it is to compete with it. To do this, panvala team built a system that represent a decentralized version of the Ethereum foundation that runs on its own token. From the other hand, the Ethereum Foundation has faced regular barrages of criticism over the years, but panvala was not built because the Ethereum Foundation has failed to achieve its goals. Panvala was built for the Ethereum Foundation to succeed at its goals. Furthermore, The Ethereum Foundation’s remaining 600,000 ETH will not last forever, and the $30 million that it intends to spend over the next year is roughly the same level of funding that competing projects are allocating even though those projects have not even launched live networks. That’s why we need Panvala’s ability to raise new funds and 4 act as a decentralized Ethereum Foundation.
More abstractly, Panvala is a system that self-organizes the provision of non-rivalrous goods. Non-rivalrous goods are cheap to provide for each additional person, like a movie theater that isn’t capacity or new research discoveries. For comparison, consider private goods: products that are hard to share, like a mobile phone or a toothbrush. Each individual pays for the private goods they can afford. Aided by government regulations, the marketplace self-organizes the provision of goods like these, so the supercomputers in our pockets and the cars we drive constantly get better, cheaper, and more efficient. But for non-rivalrous goods that can be shared, Panvala pays for what it can afford. It self-organizes the provision of shared goods, and constantly improves them to earn and retain the loyalty of the people who donate to it.
II Main operating modes of the platform
Grants
Panvala grants are awarded to teams who work to fulfill the Ethereum vision with infrastructure and applications that the whole ecosystem depends on. Grants are issued using the system’s own token, so they can be issued from the first day of the system. The value of these early grants cannot be determined until there are people who want to buy the tokens. The intended buyers of the granted tokens are donors who want to fund these ecosystem development projects.
Panvala puts very few restrictions on grant issuance.
1- The token has a fixed supply of 100 million tokens.
2- The rate that donated tokens can be released is limited by the token capacitor.
3- The token holders must govern the issuance of grants using slate governance.
Other than these three restrictions, the token holders are free to structure their spending of released token however they would like. Since most non-equity funding in our community operates using grants, we have adopted that model as the default. However, the system can also accommodate a budget model, where teams receive recurring funding to perform an ongoing function, in addiction to project-based grants to teams that pursue a variety of funding sources.
Donations
Panvala is designed to organize a flow of funds towards work that its community wants to support. While Panvala’s grants are issued to individual teams, donations are made to the system as a whole, not to individual projects. These donations are made using Panvala’s native tokens. Panvala’s tokens can be acquired with more liquid currencies like USD, KRW, and ETH, but Panvala has no ability to hold any currency other than its own. Donors buy tokens from teams who did work (directly from teams, or indirectly via exchanges) then donate those tokens back into the smart contract they came from. That’s what completes that cycle that makes Panvala sustainable. Additionally, buying tokens from a team that received a grant is necessary, but not sufficient to make a donation. A team that sells its tokens now has money to fund its work, but the buyer of the token has three options: donate the tokens back to the system, hold on to the tokens indefinitely to vote on Panvala’s decisions, or hold on to the tokens in order to sell the tokens later. When a donor buys resold tokens, their purchase does not fund any work. That’s why the purchase of tokens from a team is not considered a donation. The donation occurs when you deposit the tokens you acquired back into the system so they cannot be resold. Meanwhile, the Panvala community recognizes the individuals and businesses who make donations to encourage more people to join them. Businesses who sponsor Panvala earn the community’s gratitude and attention based on the annual pledge required for their sponsorship package. Individual Panvala patrons are recognized by the size of the recurring donations they have pledged to make. The benefits of these programs are fulfilled by token holders, grant recipients, and the whole Panvala community, not by the Panvala Launch Team.
III Team members
Since July 2 017, the panvala launch Team has been building Panvala at ConsenSys. The team consists of Niran Babalola, Romana Basilaris, Daniel Schifano, Jacob Cantele, Akua Nti , and Isaac Kang.
- Niran Babalola the founder of panvala is a member of Meta_Cartel and an economist performance artist, previously wowrk stations: a Product Engineer at ConsenSys, a Product Manager and Senior Software Engineer at TabbedOut.
- Accounts:
- LinkedIn: https://www.linkedin.com/in/niranbabalola
- Twitter: https://twitter.com/niran
- Github: https://github.com/niran
- Isaac Kang known under “_kangarang” is a hard-working software Engineer who loves working on world-changing software products. Currently working as a software developer at Consensys and Treum.
- Accounts:
- LinkedIn: https://www.linkedin.com/in/isaackang
- Twitter: https://twitter.com/_kangarang
- Github: https://github.com/kangarang
- Jacob Cantele previously served as Chief Technology Officier for Concierge Auctions, the largest online marketplace for luxury real estate, he is an innovator and technologist who belives in expert generalism, jacob’s extensive experience entails web applications and software engineering, the Lean Startup Methodology, Ethereum blockchain.
- Accounts:
- LinkedIn: https://www.linkedin.com/in/jacob-cantele202286a5
- Twitter: https://twitter.com/jacobcantele?lang=en
- Github: https://github.com/jacobcantele
- Daniel Schifano is an enthusiastic and passionate about designing innovative, engaging products that deliver both business value and a great experience for users who previously work at ConsenSys as a Product Design Lead, Rangle.io as a Senior Product Designer & Consultant.
- Accounts:
- LinkedIn: https://www.linkedin.com/in/daniel-schifano/
- Twitter: https://twitter.com/danielschifano?lang=en
- Github: https://github.com/danielschifano
- Akua Nti is a Protocol Engineer at ConsenSys, she is one of the panvala launching team.
- Accounts:
- LinkedIn: https://www.linkedin.com/in/akuanti
- Github: https://github.com/akuanti
IV. The panvala governance mechanisms
Slate Governance
Panvala makes decisions using slate governance at each quarter, the system approves one slate of actions and all of the individual proposals it contains. Moreover, the Pan holders who don’t believe that a slate represents the consensus of the community can propose a competing slate of proposals. Additionally, Pan must be staked on each proposed slate, and the tokens staked on losing slates are donated to the token capacitor.
Each slate is associated with the recommender who authored the slate. While most on-chain decision-making systems involve approving or rejecting individual proposals, the main question that is answered is “which decision- making process should be used?” The recommender of a slate always represents a particular decision-making process, even if it is poorly defined. When done well, recommenders make their decision-making process clear, and their recommended slate represents the output of that process. Some example processes for recommenders include voting off-chain, electing representative bodies, or relying on reputable authorities. From another point, challenging individual proposals is done within the process that the recommender has already defined, where challenging a slate is like amending a constitution: you change the rules when they no longer serve the community’s goals, but not because you’re unsatisfied with a particular outcome.
Design Goals
Slate governance was designed to avoid common pitfalls seen in decentralized systems. The systems that have been deployed so far often see large numbers of decisions made, but low voter has been a signal that token-based voting might not actually be rewarding the effort it takes to evaluate decisions. Other systems see too fee decision: Bitcoin has been famously resistant to change over the years, for better or for worse. panvala team see this inertia as an emergent outcome of Bitcoin’s fork-based governance rules. The principles that justify resistance to change have been post hoc rationalizations of an emergent phenomenon.
Fork-based governance has also made its way to on-chain systems. TheDAO was a fork-based organization in which token holders could fork off a new organization after any decision they didn’t want to cooperate with. (TheDAO was hacked before we could see whether its design would work) Moloch DAO follows in TheDAO’s footsteps 5 with its “ragequit” functionality: during the waiting period after each approval, anyone can withdraw their remaining Ether if they don’t want to support the proposal. These designs make it easy to decide to join since there’s no real commitment, but their potential is constrained by the need to play it safe to keep people from leaving. Panvala avoids fork-based governance with the goal of building a committed community that cooperates even when they don’t get their way.
When it comes to on-chain voting, panvala team thinks this kind of voting has a poor track record and should be used as a mechanism of last resort rather than in the typical operation of a system. Their approach is similar to Plasma, a blockchain scaling strategy that builds child chains that can be entered and exited via a root contract. When a Plasma child chain is operating normally, very few transactions are sent off chain. When something goes wrong, that could trigger thousands of transactions to the root contract on the blockchain so people can remove their assets. Similarly, when everything is operating normally in Panvala, very few governance transactions are sent. During times of discord or attacks, thousands of transactions can be triggered for votes to be tallied to resolve the problem.
Resources and Permissions
Many designs for on-chain governance are oriented around approving transactions for a shared account to send, allowing token holders to collectively perform the same actions that a person can send a transaction to execute. Traditional multisignature wallets are the simplest form of this design, and Aragon DAOs are complex, token-based designs that control a single Aragon Agent that sends arbitrary transactions. Panvala avoids this design primarily to avoid becoming a shared pool of assets. Since Panvala cannot send transactions, it can’t hold any assets other than its own token. Instead of sending arbitrary transactions, Panvala’s resources allow anyone to request permission to interact with them. A resource is any smart contract (like the token capacitor) that defines permissions, which are then fed into the gatekeeper for approval. The gatekeeper contract is where token holders create slates of permission proposals, and vote on them if necessary. Resources call two functions on the gatekeeper:
Resources store the permission identifier returned from request Permission along with bookkeeping information about each permission request so they can check if the permission has been granted, ensure that one-time use permissions haven’t been used already, and execute the desired action. For instance, the token capacitor stores Proposal structures for each request to withdraw tokens:
Keeping track of the gatekeeper instance that was used for each proposal is particularly important to ensure that upgrades of the governance contracts go smoothly
Slates
A slate contains zero or more permission requests for a single resource. Slates are authored by recommenders, who can choose whether to stake pan on their slate to add it to the contest. If the recommender doesn’t stake on the slate, someone else must stake on it or the slate will be ignored. Each resource has its own set of slates that compete to approve permissions each quarter. As a result, each resource has a separate contest occurring each quarter. Some resources might trigger a vote during the same quarter that other resources have no contest. Meanwhile, if a resource only has one staked slate during a quarter, that slate automatically wins, and its permissions are approved, while the slates submitted without any permission requests to approve are called blank slates, these blank slates can be recommended when the consensus of the token holders is to take no action for the quarter.
Incumbency
Recommenders represent an off-chain process for reaching consensus about which permissions to approve. Panvala highlights the identity of slate recommenders to focus the on-chain decision away from the merits of the permissions on a slate and towards the process by which those permissions were added to the slate. The recommender of the last successful slate for a resource is the incumbent for that resource. The incumbent is effectively the embodiment of the bylaws that are currently in effect. If the incumbent’s slate loses a contest, it’s not just their proposals that were rejected, it’s the implicit bylaws they represent that were rejected. Hopefully, they were replaced by better bylaws. As a special case, if no one submitted a slate for a quarter, the last incumbent persists. “Incumbency can never be vacated”.
Voting
Panvala uses a commit-reveal process to tally votes. During the commit phase, voters submit a hash of their vote, while keeping the vote itself and a random salt secret. During the reveal phase, no new commitments can be made, and earlier commitments can be revealed. This approximates the experience of typical elections where no running tally of votes is available until the polls close.
Each token can be used to acquire one vote. To acquire voting rights, your tokens must be deposited in the gatekeeper contract before or during the commit phase, and cannot be withdrawn until the commit phase is over. This prevents the same tokens from being used to acquire multiple votes. Voters can delegate their votes to another Ethereum account. This allows voters to store the keys that control their tokens safely while delegating to a frequently used key that cannot withdraw the tokens. As a default action, if there is an active contest but no one votes, all slates for that resource are rejected.
Ranked Choices and Runoffs
When a contest has two competing slates, the slate with more votes wins. However, when a contest has three or more competing slates, voters can indicate their first and second choices for slates. If any slate gets more than half of the first choice votes, that slate wins. Otherwise, all slates but the top two recipients of first choice votes are eliminated. Any second choice votes for the top two slates are counted for voters whose first choice was eliminated. The remaining slate with the most votes wins. Taking the demonstration below:
Epochs
Each period of governance is called an epoch, and lasts thirteen weeks. Epoch zero started on November 2, 2018 at 1700 UTC and ended with the issuance of Batch One of grants on February 1, 2019.
Epoch Number | End of Epoch | Time (UTC) | Time (Austin, TX) |
The first deadline within an epoch is the slate submission deadline. After this deadline, no more slates can be staked or recommended for the given resource. The hard deadline for slate submission is eleven weeks into an epoch, but to prevent slates from being snuck in at the last minute, a soft deadline starts 5.5 weeks into the epoch, and adjusts as slates are submitted. Each time a slate is staked for a resource, the soft deadline is reset to be halfway between the current time and the hard deadline, which makes the soft deadline approach the hard deadline with each slate submission. As a result, each resource can have a different soft deadline for slate submission. At the end of week 11, the voting commit period begins and lasts for one week. At the end of week 12, the voting reveal period begins and lasts for one week. Once the epoch has ended, no more votes can be revealed, so the contests can be finalized and permissions approved for the winning slates. Each permission request expires at the end of the following epoch.
The Parameter Store
The parameter store holds key-value pairs that are subject to Panvala’s governance process. The parameter store gives us a common API for proposing, approving, and executing changes to parameters instead of needing different functions to be called to change different parameters. This pattern was inspired by the “Parameterizer” contract from the original token-curated registry implementation.
Initial Parameters
Upgradeability
While the token capacitor and parameter store contracts cannot be changed, the gatekeeper contract is designed to be upgraded over time. Rather than the upgradeable contracts pattern popularized by OpenZeppelin and Aragon where a contract maintains its address and storage while the code changes, Panvala team uses an older “EternalDB” pattern popularized by Peter Borah and the Colony team . In the latter 78 pattern, state is stored separately from code, and the address of the code that controls access to the state changes with each upgrade. This “EternalDB” is the parameter store. Rather than having a modifiable owner that pushes authorized changes into the contract, the parameter store pulls changes from the gatekeeper contract, which is specified by a parameter as well. As long as the new gatekeeper contract follows the permissions API from the original contract, the new version can implement whatever decision-making logic that is needed.
Updating the gatekeeper points all relevant contracts away from the old gatekeeper and towards the new one. Since the epoch in which the gatekeeper is changed can contain many other decisions as well, the upgrade approach taken by the community has significant potential effects. Permissions will function as expected during the transition as long as resources store the address of the active gatekeeper alongside each permission to ensure that permission lookups aren’t misdirected by gatekeeper upgrades. In addition to that, Token balances and delegations can be transferred by individual voters, but care must be taken to inform voters of the transition with enough time to prepare. Incumbents are harder to transfer: since the new gatekeeper must be deployed before the permission has been granted to upgrade, the new gatekeeper won’t know the incumbents from that epoch unless it was written to be able to fetch them. In this context, gatekeeper upgrades have three options when it comes to transitioning state: they can do a clean break that loses incumbent data, they can fetch the incumbent data and anything else they’d like to transition in an initialization function on the new gatekeeper, or they can preserve all state using Merkle proofs or a new gatekeeper contract that uses an upgradability pattern that updates the code within a contract. If no other known contracts are using the incumbent data, clean break upgrades should be fine, but third-party contracts may have begun relying on the data without notifying you. Fetching the desired state to transition avoids breaking known or unknown contracts that rely on incumbent data.
Governance Demonstrations
The first demonstration of slate governance was performed by the Panvala Mark Council, a group of Ethereum community members that was appointed for this purpose. On October 25, 2018, the Panvala Mark Council convened to recommend issuing a Panvala Mark for a simple multisignature wallet smart contract. From the other hand,
Error Recovery
Smart contracts are rigid programs that are difficult and risky to modify after they have been deployed. Many contracts in other applications have had bugs and security flaws. While the team took the best practice precautions to avoid these issues, it’s still possible that problems will arise that we haven’t foreseen. In the event of a serious error, the incumbent recommender for the token capacitor resource should make a recommendation for recovering from the error. In some cases, it might be easy to deploy fixed versions of the contracts with a new token that copies the balances at the time the error occurred. More complicated errors might be more difficult to recover from. Since Panvala only holds its own token, all errors can be recovered with a new instance of the system. Determining the initial state of that new instance is the hard part, and the incumbent recommender for the token capacitor should lead the community towards a consensus.
IV. The panvala incentive mechanisms
The Panvala Token
The token of Panvala is the pan. When specifying amounts of pan, the symbol is used before the amount. For instance, 5000 might be required to stake on a slate, and a batch of grants might have 2 million available. “PAN” is used to represent the token of Panvala when trading on exchanges or in any other context where a ticker symbol is useful, alongside USD, KRW, and ETH. When the full name of the token is needed (e.g “United States dollar” or “Korean won”), the token is the Panvala pan. Pan is both singular and plural. Instead of coordinating donations by pooling money and spending it on workers, Panvala coordinates donations by issuing grants of its own tokens to workers. Donors buy those tokens and donate them back to the token capacitor. There is no way to donate dollars, won, or Ether directly to Panvala. Those currencies are used to acquire pan from workers and donate it back to the system.
Purposes of the token
Property Rights:
Using property rights to organize cooperation makes it easy for people to do work and be rewarded for it without needing anyone’s approval to do so. As a result, people capable of improving property can identify themselves without needing to be recognized by a central planner. A normal foundation hires donor development staff to increase the flow of donations into the organization. Instead of having a handful of donor development employees who are rewarded for increasing donations, Panvala can tap thousands or even millions of token holders, who can all be rewarded for increasing donations to the ecosystem. The more donations are made to the system, the more demand there is for the tokens held by the people recruiting more donors. Token holders have an incentive to tap their social networks to recruit more donors to fund the work we all care about.
Principal-Agent Alignment:
Many donor-funded organizations are ineffective. The management of these organizations act as an agent for their donors, who expect them to maximize the good that can be done with their donation. However, since their effectiveness is hard to measure and often defined subjectively by a handful of large donors, the management of the organization can be far removed from any increases or decreases in their effectiveness compared to for-profit organizations where there are clearer measures of impact. It is notoriously difficult to solve principal-agent problems and get agents to act in the interests of their principals. In Panvala, pan holders are the agent for Panvala’s donors. Pan gives its holders a stake in the system’s future. If pan holders vote to issue grants effectively, they will grow the number and size of donations made to Panvala, which increases demand for the pan they hold. If they issue grants poorly, donations will decrease, as will demand for their holdings. As a result, we expect pan holders to be very responsive to the desires of current and potential donors, even though donors themselves don’t have votes in the system.
Subsidiarity:
While each token gives influence over all of the system's actions, they also create a locus for subsidiarity to allow decision-making to be pushed down to lower levels of Panvala. Some organizations divide themselves by geography or by function, but the team expect that the most effective way to divide Panvala will be by pools of staked tokens. Today, the individual donors to Panvala are recognized at the top level of the system, but in the future, it might be the staking pool those donations are assigned to that matters the most. Those staking pools can then be evaluated and recognized based on a function of the number of tokens in their pool and the size of the donation flow they have organized.
Unit of Account
Donations are measured in Panvala’s unit of account, not in pan. At launch, Panvala’s unit of account is equivalent to 1 USD, and while this remains true, we avoid mentioning the unit of account in favor of just using USD. However, we expect that Panvala’s unit of account will be adjusted over time to achieve stable values for as much of Panvala’s global community as possible. When that happens, the unit of account will be named by the token holders.
Initial Distribution
Panvala started issuing grants on February 1, 2019. At that point, 50 million pan were held in the token capacitor, and the remaining 50 million pan were reserved for distribution by the Panvala Launch Team. Through August 2, a total of 6,093,697 pan were issued in Batches One, Two and Three of grants, leaving 43,906,303 pan in the token capacitor. From the 50 million pan for the Panvala Launch Team to distribute, the team retains 20 million pan. ConsenSys holds 5 million pan, plus another 5 million pan for projects at ConsenSys that the whole community can use, like MetaMask, Truffle, and the Burner Wallet. ConsenSys was allocated an additional 6 million pan, but chose to donate them back to the token capacitor for future grants. (As a result, the token capacitor will be initialized on chain with a balance of 49,906,303 pan.) 500,000 pan will be deposited in Uniswap, which is the default method for donors to acquire the tokens to donate. Advisors hold 3,500,000 pan.
Launch partners hold the remaining 10 million pan. Launch partners are selected grant recipients from Batches One, Two, and Three who have committed to donate by earning or purchasing pan over the first two years of Panvala. They each have monthly donation targets that must be met for these tokens to be released, which can be made up to three months in advance. If they fall more than one month behind, the remaining tokens assigned to them will be donated to the token capacitor. Lastly, All pan begins in the hands of people who have done work to fulfill the Ethereum vision. All pan other than grants are subject to vesting: one pan vests for each pan released from the token capacitor.
The Token Capacitor
The token capacitor is the smart contract that releases tokens for grants and accepts tokens as donations. The tokens in the capacitor are released at a rate that decays exponentially over time. Panvala’s token capacitor is configured with a half-life of 1456 days (four 52-week years), like Bitcoin’s block reward decay. This half-life is informed by the practices of other digital currencies, as well as common practices for issuing shares of corporations. However, it’s still just a guess. We’ve hardcoded this value not because it’s definitely the right choice forever, but because we believe that making it easy to alter the release curve would deter participation. Withdrawing tokens from the token capacitor requires permission to be granted through the slate governance process. That process has its own timeline for granting permissions, but the token capacitor itself does not enforce restrictions on the timing of withdrawals. It only restricts the amount of tokens that can be withdrawn based on the balance after the last withdrawal or donation, the time of that change, and the amount of time that has elapsed since then
Exponential Decay
The token capacitor releases tokens at rates such that its balance decays exponentially. Ideally, this decay would follow the formula for exponential decay:
N(t) is the new balanace,
is the previous balance,
t is the amount of time that has elapsed since tokens were last released, and
is the half-life of the token capacitor, 1456 days.
However, since the floating point operations needed to implement this formula have determinism issues, it’s a poor fit for execution on a blockchain, where thousands of nodes need to agree on the result. The Ethereum Virtual Machine does not include floating point instructions for this reason. This led the team to two attractive approaches for implementing exponential decay: store a lookup table for pre-calculated values of the decay factor for selected values of t, or create a schedule of release rates to approximate exponential decay with a piecewise function. Moreover, It is easier to verify that a particular implementation of a piecewise schedule is free of any flaws that could throw off the supply policy of the system. Piecewise functions are deterministic, while attempting to approximate the curve more closely leads to behavior that depends on the prior sequence of balances and multipliers used from the lookup table. In addition, since the goal of these smart contracts is to build consensus within a large community, it’s useful to be able to communicate exactly how many tokens should be released when using math that the public can do in their heads. Bitcoin’s block reward schedule also approximates exponential decay in this manner. However, Panvala’s token capacitor releases are based on the current balance, not the current time like Bitcoin. Bitcoin can read from the clock to determine how many halvings have occurred, but Panvala would have to store or calculate the balance boundaries for each release rate. With donations, the balance can fluctuate unpredictably, and any piecewise schedule implementation would have to account for releases that cross boundaries of the schedule. Together, these concerns increase the complexity of the implementation to a degree that accepting the flaws of the lookup table approach is the right tradeoff to make.
Creating the Lookup Table
To create the lookup table, firstly a selection of the smallest time interval that the table will support have to be done. The smaller the interval, the larger the error from truncation that compounds with every iteration. To use these multipliers with integers, a precision level to multiply by before using the multiplier is used, then divide out the precision factor when finished. One day was chosen as the smallest interval and 1 × 10 as the precision factor. Together, they produce an error of about 531 tokens 12 out of 50,000,000 over one half life. The team fill the rest of the lookup table with powers of two to be able to maintain more accuracy when more time has elapsed between the capacitor’s balance changes. However, they expect to achieve a flow of donations that exceeds one per day, which would cause the multiplier for one day to be used far more often than any other. Each time a multiplication by a multiplier is done, any present error compounds. As a result, using multipliers for fewer elapsed days over and over releases slightly more tokens than performing fewer multiplications using multipliers for more elapsed days.
Locked and Unlocked Tokens
The total balance of the capacitor is divided between locked tokens and unlocked tokens. Unlocked tokens are the only ones that can be withdrawn, and locked tokens are the only tokens involved in decay calculations. Each time tokens are received or sent by the capacitor, the tokens are moved from the locked balance to the unlocked balance before adjusting to any request to deposit or withdraw tokens. If the unlocked balance were updated after a deposit, that new donation would be included in the balance of tokens to be decayed as if the tokens had been there since the last balance update. If the unlocked balance were updated after a withdrawal, withdrawal might be incorrectly rejected if the tokens to withdraw weren’t unlocked yet.
A standalone function is available to sweep the appropriate number of locked tokens to the unlocked balance by the following method:
1. Calculate the elapsed days since tokens were last unlocked.
2. If the number of elapsed days is odd, multiply the locked balance by the lowest multiplier. Divide by the precision factor to determine the number of tokens that remain in the locked balance.
3. Add the difference between the previous and new total of locked tokens to the balance of unlocked tokens in the contract’s storage.
4. Divide the elapsed days by two, shift to the next multiplier, and repeat steps 2-5 until no time is remaining. This will take log2 (t) iterations, and will release tokens for up to 4095 days in one transaction.
5. Store the difference between the total token balance of the contract and the balance of unlocked tokens as the new locked balance.
6. Add the elapsed time to the last unlocked time.
Anyone can send a transaction that unlocks tokens and advances the last unlocked time by a given number of days that is less than or equal to the total elapsed time since tokens were last unlocked. Multiple transactions will be needed to bring the contract up to date if 4096 days or more have elapsed since tokens were last unlocked. Before processing a donation or a withdrawal, this function is called within the same transaction to minimize the number of transactions needed to keep the capacitor state up to date. Additionally, when permission has been granted to withdraw tokens, the number of unlocked tokens is reduced by the withdrawal amount. Withdrawals greater than the number of unlocked tokens revert the transaction. While donations are added directly to the locked token balance.
Recording Donations
Donations are recorded along with metadata to let the public know the context of the donation. In particular, it’s valuable for the public to know the donor’s intent and their view of the market when the donation was made. The current price of ETH/USD, current price of PAN/ETH, the intended donation in USD, and the terms of the pledge the donor intends to fulfill are useful context to record as metadata for donations.
Donation Strategies
The token capacitor coordinates donations in a new way that is difficult to reason about since no one has done it before. Panvala team thought through a hypothesis of the dynamics that they expect to play out. Large, one-time donations have no effect on the long-term flow of donations, so they do not increase the system’s ability to fund work over the long run. It’s not much different from directly funding work as an individual, but Panvala’s goal is to build up a flow of funding that teams can count on. On the other hand, long-term commitments to recurring donations can change the flow of donations for an extended period of time, which allows more work to be rewarded using fewer tokens. Teams that expect Panvala to receive a steady flow of donations can stabilize their expectations of what the tokens can fund, which allows them to plan ahead to do work for the Ethereum ecosystem rather than finding private companies to hire them. Donors who are long-term token holders are faced with a choice: should they buy new tokens to donate, or should they donate from the tokens they already hold? While both options are valid donations, donating by reducing your long-term holdings of Panvala tokens has counterintuitive effects. The purchasing power of the next batch of grants is dependent on the flow of tokens acquired, not the balance of tokens in the token capacitor. Donations that add tokens to the token capacitor but don’t involve newly acquired tokens have no effect on the purchasing power of the system: the tokens released each quarter just allocate the value flowing into the system from workers and token buyers. The increase in tokens granted will be accompanied by a decrease in the token price if the flow of value to acquire tokens stays the same. To make the largest impact with donors donations , view them as coming from their income rather than their holdings. Donate tokens immediately after acquiring them, whether the donors earned them directly for work, or purchased them from someone else. To make an impact with tokens that they held onto, they should hold them indefinitely and use their voting power to steer the system. Ideally, make an impact in both ways: holding tokens to vote while donating regularly from the income has the largest positive impact on Panvala’s capacity to fund the work that participants enjoy donating to.
PAN Token Economics
Panvala’s matching funds don’t come from a foundation or wealthy benefactors. Participating in Panvala allows communities to create their own matching funds. Panvala’s economics are modeled on Bitcoin, which funds the network using inflationary block rewards. When a participant hold his/her BTC, they are opting into a system where they know thei holdings will be diluted up to the maximum supply of 21 million BTC to fund block rewards for miners. Similarly, Panvala’s stakers have opted into a system where they will be diluted up to a maximum supply of 100 million PAN, and the Panvala League’s communities allocate that inflation themselves.
Net Inflation
A key difference from Bitcoin's model is that in Panvala, all donations go back into the decaying supply. That means the supply curve doesn't project the actual circulating supply in the future, it projects the maximum supply. In reality, every donation reduces the actual circulating supply.
The model in the chart above reaches equilibrium at an annual budget around 1,000,000 PAN that can be sustained indefinitely. In the long run, the flow of donations puts downward pressure on the circulating supply that fluctuates based on economic conditions. Those fluctuations are a result of changes in the value of PAN, and changes in the flow of donations.
To get an idea of what these fluctuations look like, consider the inflation for the past few quarters. The value of PAN increased through each quarter, but between July 3 and October 10, PAN's price increase outpaced the increase in the value of the donations. As a result, the quantity of PAN donated decreased from 355,105 to 158,206 even though the dollar value of those donations increased. The maximum inflation allowed by Panvala's smart contracts decreases each quarter, but since donated PAN are removed from the circulating supply, the net inflation actually increased between those two quarters!
Endgame
Once the circulating supply reaches equilibrium in a decade or two, there are no inflation subsidies available: for every token going into the token supply as a donation, there's one token coming out as inflation. This is similar to the end goal for the Bitcoin network to rely only on transaction fees instead of block rewards.
Over time, Panvala will approach its maximum supply, and the inflation subsidies will decrease. The panvala team hypothesis is that they could have a decade or two of healthy inflation subsidies before they taper off. That’s why Panvala doesn’t just pursue inflation subsidies for communities: they pursue all possible subsidies for communities. As the inflation subsidies taper off, they aim to build up corporate sponsorships to keep funding flowing to Panvala League communities. That’s what makes Panvala the sustainable treasury for communities to share: our approach can keep subsidies flowing in perpetuity. As a result, the share of PAN the participants hold is the share of Panvala's subsidies that their communities will be able to enjoy in perpetuity. If BTC is digital gold and ETH is digital oil, PAN is a digital endowment for the community.
VI Contract address
Contract | Mainnet Address | Filename |
PAN ERC20 Token | ||
Gatekeeper | ||
Decaying Supply | ||
Reserved Supply | ||
Parameter Store |
VII Other Informations
Official Website: https://panvala.com/
Social Media:
Twitter: https://twitter.com/PanvalaHQ
Discord: https://discord.gg/TBpv2R72
Medium: https://medium.com/@Panvala
Github: https://github.com/Panvala/panvala
Block explorer: https://etherscan.io/token/0xD56daC73A4d6766464b38ec6D91eB45Ce7457c44
欢迎提交你的DAO研究到邮箱：daorayaki@dorafactory.org,瓜分10000USDC赏金池！欢迎访问DAOrayaki官网（daorayaki.org）
详情请参考：
Dora Factory支持去中心化DAO研究组织DAOrayaki
历史文章：
罗宾·汉森经典论文（四）|Futarchy：工程设计25个问题
罗宾·汉森经典论文（三）|Futarchy：工程设计25个问题
