DAOrayaki Research |PANVALA：A Decentralized Ethereum Funding Platform

DAOrayaki

29 min readJun 10, 2021

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.

Chinese Version:https://daorayaki.org/quan-fang-wei-jie-du-panvala-qu-zhong-xin-hua-de-yi-tai-fang-zi-zhu/

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.

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.