The accrual rate of UBI can be connected to the activity aimed at growing the Proof of Humanity network. Users that are spending gas to vouch for other humans, will be rewarded with more UBI than those that are not contributing to the growth of Proof of Humanity.
Taking into consideration that the current accrual rate is 0.00028 UBI per second (or 1.00 UBI per hour), users will be able to earn the full rate if they vouch for at least one human in Proof of Humanity. If a user has never vouched for someone, she can still accrue UBI but at a fraction of the full accrual rate. We suggest to lower the accrual to 1/10th the rate (ie. 0.10 UBI per hour).
Development
The UBI token contract will be upgraded with a new interface to Proof of Humanity that will have the ability to call getSubmissionInfo and obtain for a given address if it has vouched or not for someone else using the hasVouched boolean value returned by Proof of Humanity.
interface IProofOfHumanity {
function isRegistered(address _submissionID)
external
view
returns (
bool registered
);
function getSubmissionInfo(address _submissionID)
external
view
returns (
bool status,
uint submissionTime,
uint index,
bool registered,
bool hasVouched, // value used for accrual rate
uint numberOfRequests
)
}
The getAccruedValue function that is called by balanceOf will then take into consideration if a given address has vouched or not and set the accrual rate based on this data.
Considerations
This will mitigate inflation of the UBI token during its initial phase and reward participants in the network that are effectively contributing to its growth.
Users that have accrued UBI before this modification will have to transfer their funds to a new address to keep their accrued UBI, or else their accrued UBI so far will be impacted by the new formula if they havenât vouched for anyone yet.
Implement a Pigovian tax on idle vouchers. The tax will progressively decrease the humanâs drip rate, based on the formula, over a period of time, until it hits zero or a minimum. Humans can work their way back to the average rate over time by increasing their vouching activity. The tax rate should reflect the following variables: Number of users onboarded to the registry As humans onboarded to the registry increase the protocolâs opportunity cost of idle participants decrease VoucherâŚ
Hi Scott, you definitely deserve credit for this idea. But afaik this implementation is slightly different because what is being proposed here is what can be done with the code today (not a theory). The project is open source and all ideas are welcomed. Fwiw I wouldâve loved if you proposed this directly on the DAO⌠feel free to do it the next time!
The premise of $UBI is that it is âuniversalâ no matter what youâve done. Therefore, rather than penalizing humans who havenât vouched, I suggest we reward humans who have.
I also like the 1ubi per hour drip for every human, vs. something smaller. So, simply increase the drip for those who have vouched.
similar to the above poster, iâm not sure about the idea of penalizing someone when it should be universal and basic.
but then again it is only 1 vouch needed so it isnât so demanding, if you have been vouched in you would in theory have one person who you would also vouch for (the person who vouched you).
but i would not want it to be adjusted to more than one vouch required though.
and similarly, to go the other way and reward vouchers doesnt feel right either.
i feel we should maybe just accept that registrations will be slow, and not let that effect the simplicity of the ubi payments.
I agree with you. There is a registration bottleneck, that is only temporary. I also think that, as from the marketing, and population side, THIS is the time (initial general interest in people) where you should open the big door and let everyone to the inauguration. That said, I also think that if you are deploying a security/monetary idea, IMHO the best is not to go changing things much, as it would go against the principle of âto everyone, the sameâ I read as a mission statement. Santi Voting is the way to clear things. Cheers.
Complementing with what is being said. The Human is supposed to vouch for humans they know and have meet physically, not just because that is the term and condition of the service but because you are economically responsible for how the human you vouch behaves in the future (no deadline here, increasing notably the decision cost). This new mechanism requires bringing new people, people you know to the platform. Its a good way to increase the user base but in my POV its deviates from the core, and tastes bad. The vouching problem, as its designed today is a gas price problem, why donât better think of ways of solving the economic barrier rather than thinking about 10x taxing (ie. thinking a way to convert on platform UBI accrued to ETH to be able to vouch without extra costs and logistics? ) or simply do not touch the economics until June where the economic barrier should decrease notably.
Hi, we are really neither penalizing nor rewarding⌠we are simply adjusting issuance to a criteria that benefits more those who contribute with at least a vouch. More like calibrating issuance so we can sustain token price and incent network growth. Nobody is being left out.
I think this is a very good idea to help the Vouching process not to get stopped. One thing that also causes people not vouching (especially if we want to get low income humans) is the cost of vouching. Could we make that this one person we have to vouch for is needed to be done X days after the person is vouched. And in this X days the person will receive the UBI amount that will be enough to cover the cost of the vouch it has to do (so this first vouch has no cost for the person).
I will vote against this proposal for the following reasons:
The description of the proposal doesnât match its technical implementation
The âhasVouchedâ variable returns whether or not someone vouch is currently in use. Not whether or not it has ever vouched. Maybe we could have given a better name like âvouchUsedâ but that wasnât pointed during reviews.
So the technical effect of this proposal would be to divide the rate by 1/10 most of the time, users would only get the normal rate when their vouch is being used, i.e. during the 3.5 day pending period (+ dispute time if any).
Conditioning the reception of UBI or modifying its rated depending of a work would alter the notion of UBI
âUâ stands for âUnconditionalâ, in practice nothing can be purely unconditional (here the condition is to be registered in POH, otherwise people could you use a bunch of address and get UBI multiple times), but itâs better to tends to this idea as much as possible.
It could incentivize people to act in an unsafe manner
If people get other incentives (except pure altruism of helping people they know), they may vouch people with a lower level of scrutiny and vouch people they donât know. This would lead to attackers having an easier time to get vouches and those people to be removed from the registry when attackers are caught.
Overall, I would not oppose giving some early stage incentive to lower the âvouch supplyâ crisis (maybe have some sort of airdrop for people who vouched, or even a lottery which would have the advantage of being gas efficient due to having few winners) due to extremely fast growth, but I donât think this proposal does that and I think it should only be a temporary measure.
In general, I agree with the main idea of the proposal. However, Iâve some concerns about the technical issues of the proposal as clesaege already mentioned. I think that those issues should be carefully reviewed.
You cannot get a list of it, but it would be possible as an interface input. The easiest way would be to check that in âstartAccruingâ. Note that it would increase gas cost of startAccruing. A more practical way to incentivize vouching could be to allow claiming UBI through a Merkle drop.
@clesaege how would the interface input work and get the data of the vouches from the poh contract?
a merkle drop implementation for an ad-hoc airdrop would require creating a pool of tokens assigned to such purpose and would be a one off event. or how do you envision implementing this?
We could require to pass the address of a party that the user has vouched in parameter of a âstartAccruingâ function (and in case of vouching with signature, the signature).
After looking at current registration growth, we have 278 people registered in less than a month. So thatâs more than 3X growth per month just by people altruistically vouching for people they know. So I believe the âvouch crisisâ is probably just temporary and as more people get vouched and registered, getting vouches would become easier and easier.
However, I agree with Clement on his concerns. This proposal is motivated by a context that is likely to be temporary and I donât see clear evidence for claiming that vouching needs to be incentivized further from the contract logic. Especially taking into account that incentives might change for the worse and the system will be more complex for users.
The community has already been very proactive in finding safe and cheap ways of vouching for strangers.
iâm definitely persuaded by these arguments, since the extra complexity that seems
to be required in order to introduce a mechanism like this might be a bit far off from the ideal implementation described above.
I think that this variable is not reachable from other contracts.
And there is no function that can display it from the PoH contract itself.
Maybe it would have been possible from mapping(address => Submission) private submissions;
but that mapping is private and does not generate any getter to interact with.
