and making a method from the events is not an option because the chain cannot read them, and recreating a process that reads them externally is a vulnerability since the addVouch event can be emitted by any address.
1 Like
Oh you’re right! I forgot it was private
@ruben re addVouch would be as good as giving a vouch… it would be reverted if its not from a verified address. i’m intrigued about the recreating a process idea.
maybe, but I don’t see how to make a process with events since these are not read by the chain, it would be all externally.
yeah… might be an expensive approach that requires an oracle or something.
1 Like
also, if only getSubmissionInfo returned the profiles vouched by that submission (or the length of the array) 
1 Like
If the UBI contract is used as intermediary for calling executeRequest(), it can be deduced if an address was used as a vouch. getSubmissionInfo will return a different hasVouched (false) after executeRequest is called.
We can check vouches made on chain through ‘vouches’, for vouches made by signing a message, the contract would need to parse the message (but then, someone could just vouch for an address which does not exist just by signing a message not incurring any fee).
To verify the vouch was actually used, we may check the status of the vouchee through getSubmissionInfo.
It would need to be check at the time of “startAccruing”.
Currently this proposal is winning with 12 votes against 6 and it is unclear what would be its effect. I encourage everyone whether or not you agree to “modify the accrual rate based on vouching activity” to vote against this proposal as it is not technically sound.
2 Likes
agreed that technically there’s a situation here.
nonetheless getting a sense of how the community feels about adjusting $ubi issuance might be helpful to understand if it makes sense to keep thinking ideas in this direction.
but this mapping will only work until the vouch method is changed to signatures. I don’t think you can make a permanent process around this.
The issue is that:
- It wouldn’t be possible to distinguish between people voting against the idea of the title and against a technically unsound proposal.
- If it passes it will lead to a dispute about the implementation.
if it passes i’ll buy some 
for sure
for the record I voted negative.
Hey all. Good discussion and points.
Will vote NO - for points raised - with following thoughts:
-
Agree with keeping UBI universal - NOT increasing or decreasing based on some test of participation or means. Other incentives should drive. Otherwise, all humans should receive at agreed drip rate.
-
Maybe vouch period decreases inversely - the more one vouches, the shorter the wait period. Would drop from 3.5 days down to 0 (for one with most vouches). Gamification to compete who can vouch for the most…?
-
IMHO, current drip rate is TOO HIGH at 1 UBI per hour. I am going to propose 0.05 UBI per hour. BUT, such requires a mechanism to MINT the other 0.95 per hour. (“5% of total time is FREE/UBI; the remaining amount of time is ‘earn-able’). This creates: 1) time/work-keeping mechanism, 2) real value staking UBI, 3) real market-making mechanism - trading time, 4) finally, a store-of-value based in time, an inflation-proof unit of measure.
AND, by reducing the drip rate by 20x … this will have opposite effect on token price! In my estimation … today’s drip rate of 1 UBI per hour should result in a market price of ~$1.25 per UBI. However, at a drip rate of 0.05 UBI, market rate should be 20x …around $25 per UBI.
The boundaries of UBI quantity must be simple! Bound only by two factors: 1) population and 2) time. The combination is Human Hours. The most valuable thing on earth. Therefore, we MUST bound UBI to a MAX drip rate of 1 per hour.
Currently, we are at MAX rate …and have no mechanism to mint the ‘non-UBI’ time. 
Both of these must be addressed IMHO.
Otherwise…I LOVE what the Kleros and Democracy Earth teams have delivered. Amazing! And I believe that the Ethereum cost structure will work itself out over time and gas costs will become negligible. Until then I support all forms of viral registration and vouching … that doesn’t mess with drip rate. 
1 Like
Yeah, I think the UBI should remain a UBI and that programs can be subventioned by the DAO treasury but not at the token level (where it introduces extra complexity, gas costs and lead to unclear token vision).
There is a vouch period in order to:
- Let time for people to challenge (with a vouch time of 0, someone can add an unlimited amount of profile in 1 transaction without anyone being able to challenge).
- Let time for the system to self-adapt to attacks (here even if someone were to find a way to get fake profile accepted, it would take him a lot of time to take over the majority of the system, but with a vouch time of 0, the system would be taken over before it can self adapt).
Assuming you estimates to be true, the current rate is better as it leads to token values which can easily be understandable (order of magnitude of 1$). High currency price are a barrier to those being used as a money (even in 2013, I had people telling me they would not buy BTC because 80$ per BTC was “too high”).
I think if we want UBI to acts as a good global money, we should keep the rate constant. Classic cryptocurrencies give the major proportion of their tokens to early team and investors, making them rich if the token succeeds. This is good for early stage (becoming widely accepted) but very bad for later stage (becoming the world currency) due to a feeling of unfairness for newcomers leading to a loss of legitimacy.
Contrary to classic cryptocurrencies, UBI is not made to increase or decrease depending of adoption. As more people join the system, the demand increases, but more tokens are created which counterbalance the increased demand (same if people exit the system, the demand decreases but so is the emission). With a constant rate, we can expect UBI to become relatively stable after its initial phase of price discovery.
5 Likes
After 6 weeks of action, I’m convinced that rate should be fixed and constant at 1 UBI per hour. Predictability on this fact alone will enable the market to coordinate a price very effectively on the long term.
9 Likes
YES!
Make that immutable like 24 hours = 24 UBI. So changing this is equivalent to changing hours per day. 
As immutable as 1 human = 1 vote.
It’ll save devs lot of headache in totalSupply equation and stream functions.
Still as a democracy we should first vote to lock this “forever” so any future change in accrued rate will require super majority of 80% votes. Governance will focus on other stuffs instead of this controversial idea of attaching strings to UBI accruing rates.
24 Hours = 24 UBI. No strings attached.
3 Likes
Agree with @0xc0de4c0ffee, we should lock in the issuance forever. Doing so would make us look a lot more trustworthy. The income can still be increased by increasing the value of the token. Any salary can be paid from the DAO (which needs its own income for the whole thing to work anyway).
I don’t think there is a democratic problem in locking the issuance rate forever since later managers are free to create a new token with other rules.
Best IMO would be if we could technically prevent ourselves from ever changing it - or we could require a 10% quorum of all users and 80% approval (super-duper difficult and if someone pulls that off they must have a point).
2 Likes
@0xc0de4c0ffee @Mads I’m in favour of making issuance immutable and require a high % with a relevant quorum to change it. We should do a HIP for this.
3 Likes