Token Underground 0x3: WTF is The Panvala Donation Platform?

By Vasily Sumanov and Olya Green

We went in-depth on Panvala platform to lay down some pain points of the existing token model for both the Panvala team and the blockchain community at large. Keen to engage in further discussion and get feedback too.

Our TU session 0x3 starts right here. This time we’re looking at Panvala — a donation platform built by Consensys that has an intrinsic PAN token and a smart-contract concept for grant funding dubbed as ‘Token Capacitor’ in place. Is it something novel and promising, or merely a spark of flashy words around a mediocre concept? Let’s dive in.

Identifying the goal and the system actors

As always, we start with the identification of system goals and application field. Here is a citation from Panvala website:

Panvala is a donation-driven platform that helps fund the work that the whole Ethereum community depends on, typically work that furthers the security or scalability of Ethereum. Our donors contribute funds to a smart contract called the token capacitor. Each quarter, our token holders use their tokens to vote on which grant applications should be funded from the token capacitor.

So, Panvala is a system developed with the purpose of equitable funding provision to important grant proposals that can make Ethereum better with focus on security.

The system actors are:

• Donors. This role comes down to providing capital that will be used for funding grant proposals.
• Grantees. The members of the community who receive funding from the system to complete grants proposals.
• Participants in the governance. Governance is designed to provide a way to make collective decisions about allocating funds. This role can be performed by any of PAN token holders.

What mechanisms are implemented to achieve the system goals?

To achieve the goal of equitable funding of proposals that really matter for the ecosystem at large they need to solve two primary tasks:

1. Collecting and distributing funds in a transparent, secure and reliable way.
2. Creating the mechanics that allows allocation of these funds equitable. It is obvious that if the decision-making about funds allocation is made in centralized mode, these decisions would involve personal preferences. It opens up huge possibilities for corruption and corporate wars (for example one team can bribe decision-makers to prevent funding of their competitors).

To tackle the first task the Panvala team proposes the “Token Capacitor” concept.

The Token Capacitor

It is a smart-contract that collects token flow from Donors and distributes them to selected grant applications as per voting results (the voting procedure will be described further in details). The system works as follows:

The Token Capacitor concept can be referred to a bath with two valves: one fills up a bath with water, while the other releases it. Quite a simple system. But, let’s look at it a bit closer.

The Token Capacitor operates with PAN tokens as the means of payment. Isn’t it surprising to find such an approach in 2019, while there are already stablecoins like DAI that can work as a stable and proven payment solution.

The description of the Token Capacitor includes the phrase “designed to be recharged.” What is meant by “recharging” is that donors will basically be sending PAN tokens to this contract to fund future grant proposals? But, to send something you first need to get it.

The default case considered by the team is that Donors buy tokens from Grantees who received grants before. Doesn’t look very convincing: what’s the point for Donors to buy tokens and for Grantees to sell them? Obviously, they need some common payment instrument, at least DAI or ETH, that can be easily used for payments in the community or seamlessly converted to fiat currency if necessary.

Besides unnecessary actions, how about another big threat for Grantees: PAN tokens can be quite volatile, so the amount of real money that they will finally get can be significantly lower than the initial value of the grant at the moment of distribution.

So, they are incentivised to sell these tokens as fast as they can, and they’d better be ahead of the other teams who will probably be doing the exact same thing.

The main problem here is that PAN doesn’t have any constant demand: all purchases of this token are connected with “Donor’s Charity”, or with the goodwill of people who donate money to this system. So, the supply after funds distribution between Grantees can be quite high for a short time after PAN tokens are released from Token Capacitor, while the demand can be low.

This will lead to high volatility for PAN tokens (unless the Panvala team will make considerable investments in the market making) that will place Grantees in a complicated situation.

The Governance

The second task defined as “make a mechanics that allows allocation of these funds equitable” evidently comes down to the design of the governance process. Here is the blog post on the alpha release of Panvala:

Panvala was originally built as a more traditional token-curated registry, before adopting slate governance as our model. Slate governance is an alternative to token-curated registries. Slate governance allows an individual or organization on our platform to curate a slate of proposals (a registry), and have that slate compete with other slates on the platform for the support of token holders. Slate governance is more similar to representation in a voting system, and solves the problem of low-voter knowledge of each individual proposal existing in a registry.

In our opinion, the proposed approach is quite interesting and potentially can be better than an ordinary TCR. Competition between slates, or a set of grant proposals, is a good idea that allows a token holder to “diversify” his votes between all grant proposals and not bet his votes on the single one. Not bad, it can work.

The stake game

The project’s team suggests one additional scenario for the token usage — the stake game — or the system for a smart-contract audit that requires a token stake for submission as the core part of the concept. It means that anyone who wants to audit this contract and earn straight A, has to stake a certain amount of tokens to prove that their code is not bullshit.

It is not a bad idea, but there’s one question — why not use ETH or DAI for this? It can motivate auditors to dig deeper into smart contract issues, because if they find security error, they get rewarded. Also, here is an open question — who are the judges?

How do we know, if there’s real error in the code, or it is just another fantasy of the auditors?

Further thoughts

Some more thoughts on“Token Capacitor” and the governance design. First of all, it is not clear which tokens can be used for voting. For example, if I am a Donor and I want to fund some proposals, I will need to perform these two functions — donating my tokens to Token Capacitor and participating in governance.

So, it is important to clarify for the tokens that already were granted to the Token Capacitor, but not distributed yet — do the previous owners have these votes, or not? If not, the Donors will have to buy a batch of tokens: one is to be used for donation, and the other for holding to be able to vote. Such an approach seems to be inconvenient and economically useless.

Also, there can be another side effect: the donated tokens are lost forever for the owner, while tokens held outside the Token Capacitor can be used many times to participate in voting and define the fate of the grant proposals. It seems that holding tokens is economically rational (at least, the holder accumulates some power in his hands), while donating is more like a charity event.

So, a situation where there are more token holders who vote than who donate is quite plausible.

All in all, the slate governance is quite interesting, because healthy competition always fosters progress.

But, there will probably be some attacks, like creating a lot of similar bets to make part votes distributed between them and simplify the task of a specific group of token holders to approve slate they are interested in.

This problem roots in the questions like “who and why can create new slates? what conditions have to be met to do so? how does the system prevent slates duplication?”

Our verdict and ideas for the team

The “Token Capacitor” idea is generally not bad, but its execution is not ideal at the moment. The PAN token that is used for value transfer purposes makes this system weak and inconvenient for both Donors and Grantees and therefore raises concerns.

Idea: running a separate version of Token Capacitor that can be filled up only with DAI and use PAN tokens to govern it. The part of funds can be distributed among voters for grant proposals that were perfectly executed like some sort of governance fee.

But here is a question of how to identify excellence of grant execution. How about integrating with Augur prediction markets? Just kidding, as market-related to grants seems to be rather illiquid, with the exception of the most important and known ones.

The slate governance mechanics is an interesting approach, but also requires clarification from the team regarding conditions for slate creation and the exact voting procedure.

Idea: defining transparent rules that will regulate participation in governance for token holders. We are suggesting to permit token holders who already donated their tokens to the Token Capacitor (despite the fact that PAN as value transfer is actually bad) participate in governance according to their token holdings that are not distributed yet.

Here is a question — how do we select whose tokens will be distributed in the next round? We think that some kind of random mechanics can solve this issue.

The Stake Game. Of course, we understand that teams are always searching for some ideas to expand the utility of their [often useless] token. In our opinion, using PAN for stakes for smart contract audit really is a joke. There is no economic sense whatsoever: the token can be replaced by any other token that is interesting in terms of being earned as a reward by auditors.

Also, the “judge for the judges” problem is also very pressing for this “stake game.” Now the exact conditions of recognition the contract as “secure” or “not secure” are unclear.

Idea: making a selection of tokens for stakes free for applicants to audit. If the applicants submit an application where some shit-token is used for a stake, nobody will make an audit. Let the market be the principal regulator for the selection of tokens for stakes.

Also, here are the two bullets from the project roadmap. In future they’re planning to implement some new features including this:

Platform governance slate creation, giving token holders control over governance parameters

Staking in order to create the necessary economic incentives around slate curation

It is quite interesting, but more information is required to make the conclusion like — what governance parameters are considered? Why are the parameters are exactly these and not some others? What values can they take? We have the same questions about the staking function.

For what purpose is the stake implemented? What will be the exact mechanics, and what economics is behind the staking idea?

All in all, the idea and the promise of Panvala donation system are pretty cool and much needed in the Ethereum ecosystem to foster its sustainable development.

But, in our opinion, the execution of this idea is not ideal at the moment and has some pressing issues on the economic side.

This article was written by Technomads: Vasily Sumanov and Olga Grinina. The more cool stuff about web3 and post-industrial economy or chat with us you can on our Twitter.

Token Underground 0x3: WTF is The Panvala Donation Platform? was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.