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
最初的创新项目是基于比特币的分叉，并在比特币链的早期历史中通过挖矿获得奖励。后来的项目有了自己的代码库，并经常 "预挖 "代币，为自己保留或出售给他们的资助者。以太坊也举行了第一次众筹活动，为创建新货币募集资金。以太坊引领了使用此类融资模式项目的爆炸性成长。目前，这种方式已经被大多数项目采用。然而，以太坊也受到了这种模式的限制。
当年，许多人致力于维护和建设以太坊网络，因为改善者认为，持有的以太币会随着网络的改善而变得更加有用。从首次发行代币到现在。代币价格已经上涨了1000多倍。这种动力已经开始变弱。任何团队都很难感受到他们的工作对以以太坊或者以太币的任何影响，但对社区的影响却非常显著。詹姆斯-普雷斯蒂奇（James Prestwich）曾观察到，"以太坊不为人知的弱点之一是它无法长期保留人才和经验"。之后，在2018年12月，致力于实现以太坊2.0的工程师Preston Van Loon在Twitter上发表了他的担忧，"我们[在Prysmatic实验室]注意力被分散，我们仍然需要完成其他工作。即使最近有下发grants，也不能让我们将团队的规模扩大到我们需要的程度。" 作为回应，维塔利克-布特林(Vitalik Buterin)在推特上说："刚发了1000个eth。Yolo！"。尽管这是值得赞赏的，但此类 捐赠模式也表明，以太坊社区中缺乏提供公共物品的机构。
Panvala grant 将发放给那些致力于实现以太坊愿景的团队，主要用于开发整个生态系统所依赖的基础设施和应用程序。grant通过Panvala代币发放。
- grant代币的发放速度受代币容器（token capacitor）的限制。
- 代币持有人必须使用推举提名治理（slate governance）来管理grant的发行。
自2017年7月以来，Panvala创始团队一直在ConsenSys开发Panvala。该团队由Niran Babalola，Romana Basilaris，Daniel Schifano，Jacob Cantele，Akua Nti和Isaac Kang组成。
- Niran Babalola 项目创始人
2. Isaac Kang
3. Jacob Cantele
4. Daniel Schifano
5. Akua Nti
- 候选集治理（Slate Governance）
Panvala在每个季度使用提候选集治理（Slate Governance）机制进行决策，系统会批准一系列候选行动和它所包含的所有个人提案。此外，不认同Slate 能够代表社区共识的pan持有者可以提出竞争性的Slate 。此外，必须在每个提议上押注pan，而押注失败的代币将被捐回给代币容器。
每个slate都与编写该Slate 的推荐者相关。尽管大多数链上决策系统都涉及批准或拒绝单个提案，但需要回答的主要问题是“应使用哪种决策程序”？Slate 的推荐者始终代表着特定的决策过程，即使界定不明确也是如此。如果做得好，推荐人将清楚地制定决策过程，而推荐的Slate 则代表了该过程的结果。一些示例包括链下投票，选举代表机构或依靠信誉良好的权威。从另一点来看，对个别提案的质疑是在推荐者已经界定好的过程中完成的，对个别提案的质疑就像修改宪法：当规则不再符合社区目标时，您就可以更改规则，但这不是因为您不满意一个特定的结果。
2. 设计目标 （Design Goals）
基于分叉的治理也已经进入了链上系统。TheDAO是一个基于分叉的组织，其中代币持有人可以在他们不想合作后，分叉出一个新的组织。(TheDAO在我们看到其设计是否可行之前就被黑掉了)Moloch DAO以其 “怒退”的机制追随TheDAO的脚步：在每次批准后的等待期间，如果他们不想支持该提案，任何人都可以撤回他们剩余的eth。这些设计使人们很容易决定加入。但因为没有真正的承诺，机制的潜力也受到了限制。Panvala避免了基于分叉的治理，其目标是建立一个承诺的社区，即使在成员没有得到想要的方式时也依然会合作。
3. 资源和权限 （Resources and Permissions）
许多链上治理的设计都是围绕批准共享账户发送的交易，从而使代币持有者可以集体执行与个人执行相同的操作来发送交易。传统的多签名钱包是这种设计的最简单体现，而Aragon DAO是复杂的、基于代币的设计，它控制发送任意交易的单个Aragon Agent。Panvala避免了这种设计，主要是为了避免成为一个共享的资产池。由于Panvala不能发送交易，它不能持有除其自身代币以外的任何资产。Panvala的资源不发送任意交易，而是允许任何人请求与它们互动的权限。资源是任何定义权限的智能合约（如代币容器），然后将其送入把关人（gatekeeper）进行审批。把关人合约是代币持有者创建权限提案slate的地方，如果有必要，还可以对它们进行投票。把关人的资源、调用的两个权限功能。
资源存储从请求Permission 返回的权限标识符以及关于每个权限请求的账本信息，以便它们能够检查权限是否已被授予，确保一次性使用的权限尚未被使用，并执行所需的行动。例如，token capacitor为每个提取token的请求存储Proposal结构。
4. 候选集 slates：
7. 排名选择和决选（Ranked Choices and Runoffs）
8. 纪元 （Epochs）
9. 参数储存 （The Parameter Store）
参数存储持有受Panvala治理程序约束的键值对（key-value pairs）。参数存储为我们提供了一个通用的API来提出、批准和执行对参数的修改，而不是需要调用不同的函数来改变不同的参数。这种模式的灵感来自于原始代币存储的注册表（token-curistry）实现中的参数器（Parameterizer ）合约。
10. 初始参数 （Initial Parameters）
11. 可升级性 （Upgradeability）
虽然代币容器（token capacitor）和参数存储合约不能改变，但把关人（gatekeeper）合约被设计成可以随着时间的推移而升级。与OpenZeppelin和Aragon流行的可升级合约模式相比，Panvala团队使用的是Peter Borah和Colony团队流行的较早的 "EternalDB "模式，即在代码改变时，合约保持其地址和存储。在后一种模式中，状态与代码分开存储，控制访问状态代码的地址随着每次升级而改变。这个 "EternalDB "就是参数存储。参数存储不是有一个可修改的所有者将授权的变化推入合约，而是从把关人合约中拉出变化，把关人合约也是由一个参数指定的。只要新的把关人合约遵循原合约的权限API，新版本就可以实现任何需要的决策逻辑。
12. 治理示范（Governance Demonstrations）
slates治理的第一个示范是由Panvala Mark理事会进行的，该理事会是由以太坊社区成员组成的小组，为此目的而任命。2018年10月25日，Panvala Mark理事会召开会议，建议为一个简单的多签名钱包智能合约发布一个Panvala Mark。
13. 错误恢复（Error Recovery）
系统的代币是pan。在指定pan的数额时，在数额前使用?符号。例如，?5000可能需要押注在一个slates上，而一批grants可能有?200万可用。"PAN "在交易所交易时或在任何其他需要使用的情况下，与美元、韩元和ETH一起用来代表Panvala的代币。当需要代币的全称时（如 "美元 "或 "韩元"），代币就是Panvala pan。Pan既是单数也是复数。Panvala不是通过众筹资金并将其用于贡献者来协调捐赠，而是通过向贡献者发放自己的代币grants来协调捐赠。捐赠者购买这些代币并将其捐回代币容器。没有办法直接向Panvala捐赠美元、韩元或以太币。这些货币被用来从贡献者那里获得pan，并将其捐回系统。
（2）委托人和代理人的一致性（ Principal-Agent Alignment）
3. 账户单位 （Unit of Account）
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。
5. 代币容器 （The Token Capacitor）
- 指数衰变 （Exponential Decay）
7. 创建查询表 （Creating the Lookup Table）
8. 锁定的和未锁定的代币 （Locked and Unlocked Tokens）
9. 记录捐赠（Recording Donations）
10. 捐赠策略 （Donation Strategies）
11. PAN代币经济学 （PAN Token Economics）
12. 净通货膨胀（Net Inflation）
捐赠结束End of Donations
净通货膨胀率% Net Inflation %
13. 终局 （Endgame）
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.
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.
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
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.
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.
- 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.
- 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.
- 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.
- 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.
- LinkedIn: https://www.linkedin.com/in/akuanti
- Github: https://github.com/akuanti
IV. The panvala governance mechanisms
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.
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
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.
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”.
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:
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.
End of Epoch
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.
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.
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,
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
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.
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.
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.
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
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.
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.
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.
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!
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
PAN ERC20 Token
VII Other Informations
Official Website: https://panvala.com/
Block explorer: https://etherscan.io/token/0xD56daC73A4d6766464b38ec6D91eB45Ce7457c44