[On Hold] HIP-14: Lock the 1 $UBI/hour/person issuance rate

HIP: 14
title: Lock the 1 $UBI/hour/person issuance rate
author: @Mads
status: Signalling
created: 19-05-2021
requires: HIP-10

Simple Summary

The proposal is to elevate the issuance rate of 1 $UBI/hour/person to a formal decision and allow no other form of $UBI issuance. Furthermore to lock the decision using the locking mechanism proposed in HIP-10.


The issuance rate of $UBI is 1 $UBI/hour/person, which seems to be very satisfactory to the community. However, we lack a decision specifying this issuance rate. This proposal formally adopts this issuance rate and bans all other forms of issuance - for instance putting tokens directly into the DAO account. In addition, the decision will be locked using the new HIP-10 mechanism, which will need to pass before this proposal can be put to a final vote. The decision is mostly about sending a signal to ourselves and others that the issuance rate is holy and will not be changed, ever.


A good currency needs dependability - if it operates under rules that are unlikely to change then people will be more likely to trust it. The burning rate question will be left open, but just fixing the issuance rate will already make future supply much easier to predict.
And future problems can be addressed within changing issuance:

  • If we need to raise the income, then we but increase the value of the token.
  • If we need money, we but get outside funding or increase revenue.

Locking Motivation

Locking the decision will send a signal to ourselves and others that $UBI will never be changed. This will deflate arguments against investing time and money in the currency because “the DAO could just put 3 million in its account at any time.”


The $UBI token will be issued at a rate of 1 $UBI/hour/human.
No other issuance of $UBI will be allowed.


This proposal was split off from HIP-10 as a separate proposal because it had too great an impact on the future of the DAO.


Some support and arguments for the idea:


I think it would be a good proposal. Let’s wait for HIP-10 to be voted first as it depends of it…

1 Like

I agree, and if HIP-10 becomes valid, there should be 2 HIP for this, one the fixing issuance and another the locking, right?

HIP-10 allows for adopting a proposal and locking it immediately. I think I could have made it more clear exactly how that works though.

1 Like

A proposal of a sensitive subject such as the issuanceRate should take considerable time to be debated and we should encourage and make sure all points of view are being shared by the community.

Perhaps the voting time should be doubled when attempting a locking proposal?
Or locking is a seperate proposal always. Removing the possibility to apply a lock immediately to a new proposal.

i’d favor an extended time period for proposal locking.

Yeah, you are right, it keeps the process simple and just slows it down.

Move to Phase-2:

  • Moving HIP-10 to phase-3, I think this proposal can pass to phase-2. I think it is ok if a proposal tails one phase behind a required proposal. Less time is spent to pass proposals while keeping quality.

NO, this proposal is NOT a good idea.

PLEASE vote no on this - as I already have. Let me explain why…

But first … for those that don’t know me or inherently trust me. Sorry if it seems I am coming in over the top or last-minute. I am not. I am a co-founder of the Democracy Earth Foundation and a sitting Board Member. I am THE person that brought the idea of UBI to Santi and Democracy Earth. I am THE person that brought Ethereum to Santi. (doubt it, ask him!). I have been working on UBI and the economics of related tokens and protocols for well over 6 years. I really care about ONE number … the accrual rate. This one.

If you don’t trust me or the above, here is the logic. And, again, sorry if I haven’t been pounding the slack channel or otherwise arguing my points in public. I am by nature a quiet thinker and the past two years have been occupied by my daughter running for US Congress (against Nancy Pelosi here in San Francisco) and this crazy pandemic.

I am SUPER proud of Santi and the entire Kleros team and Proof of Humanity launch! Wow … truly amazing. Brought tears to my eyes. Still does. Powerful what has been launched and what is ahead.

My reasons:

  1. Stated arguments simply not strong - actually seem emotional or price-motivated.
  2. Way too early. We can always lock the protocol later. Biggest mistakes DAOs make … locking things too early.
  3. Breaks economics of linking token to time. (which UBI is a factor of … relative to working time and time in given day/month/year, working year). Needs longer discussion here … but at 1 UBI per hour and 24 UBI per day is FULL THROTTLE … 100% of time. [see more math, below]
  4. Eliminates ability to increase UBI. Ray Kurzweil predicts “none will have to work by 2050”… meaning we need to ramp up UBI between now and then (straight line? bounding curve? yearly % increase?). Some rate! (the community determines and then adjusts)
  5. Note: argument above is weak that we can somehow increase the price in the future. NO. Just as with minimum wage … the system does not automatically adjust or have mechanism to do so. We must start with a LOW drip rate … and then increase to a MAXIMUM of 0.25 UBI per hour.

More math, explanation:

I AGREE that we need to send and enact proper signals to the market! Yes, we should set a maximum drip rate of UBI! But, such drip rate should NOT be the maximum rate [24/day] … it should be a fraction of such.

Here’s a question I have now asked well over 10 very smart individuals: “If you get 24 UBI per day … what should the price of UBI be?” [and, please, ask yourself this … and do the math yourself]

All have come to the same conclusion. (ballpark)

The person I asked this morning was in London. His conclusion: “between 1 and 1.5 pounds”. The correct answer.

In the U.S. … the mental math is: "hmm, UBI should be about $1000 to $1500 per month … and I am getting 24 UBI per day … ~30 days per month … equates to ~720 UBI per month. $1500/720=$2.08 and $1000/720=$1.38 … so avg price of UBI should be $1.73.


  1. We should be patient. Talk this through. Not rush a proposal prematurely. Happy to answer all questions re: above.
  2. We should (YES) limit UBI to a max issuance rate: 0.25 UBI per hour.
  3. We should change current rate of 1 UBI per hour to 0.05 UBI per hour. (ramping via governance to 0.25 UBI per hour BY 2050). **

**math per above: If I get 1.2 UBI per day … 30 days per month … 36 UBI per month … and I think $1250 is the right amount of UBI per month … then $1250/36 = $34.72. <<>>. Yes, it works in reverse: set the accrual rate lower … and the price increases! (supply lower…price higher).

I will stop here … but PLEASE, DO NOT vote yes on this. VOTE NO.

Let’s take our time to discuss and understand my logic. :slight_smile:



Thanks for your comment and debate, Herb. I don’t totally follow your argument, though. Maybe you could connect the dots?

I follow the logic of coming to $1000–$1500 per month. I thought the same. And so we’d want the price of UBI to somehow rise from $.20 to $1.73.

But then in your arguments that we should limit and change the rate, I don’t get the because aspect:

  1. We should (YES) limit UBI to a max issuance rate: 0.25 UBI per hour.

Because … ? Why? What will that achieve?

  1. We should change current rate of 1 UBI per hour to 0.05 UBI per hour.

Why? I think your argument is that by lowering the rate, the price will go up. But I don’t see how you can make that claim. You don’t say what will cause that change. You do math to show what the market price should be with a lower rate ($34.72) … but I don’t see the causation. I.e., How does merely lowering the rate to 0.05 per hour raise the price from $.20 to $34.72? You don’t say.

My view: Yes, lock the rate at the current 1 per hour.

Because: It helps make the entire system understandable and easier to use and plan with. The rate itself is arbitrary as I understand it. And so “1 token per hour” is conceptually easy, making at least one small part of UBI constant even though there are many other variables. I also like the consistency that this signals to the market.

I could be persuaded to change my mind if there was some real difference between (say) .1 per hour vs. 1.

1 Like

I do support your reasoning direction but there’s 2nd (& 3rd) side of same coin… Here’s my reasoning for/against your arguments.

  1. We should settle this issuance debate for now, else we’ll have more HIPs trying to change accruing rate or attach strings for different reason / every season.

  2. 1 UBI per hour, 24 per day is part of psychological UNIT bias in accruing rate design. 100/10/0.5 UBI per day is same maths on % of total supply per human. It’s not related to USD units/ my national currency. We’re our own virtual nation. :slight_smile:

  3. Changing this rate anytime will create ripple effect for/against 1st movers and everyone involved. Lowering UBI accruing rate as more humans join will increase already maxed out 1st mover advantage. Increasing accruing rate as more humans join will be same on top of maxed increasing inflation.

  4. Settling for 24 per day will give us more predictable inflation per human timeline. Still we can make people select their accruing rate from 1~24 UBI per day during registration, people can decrease their rate anytime or increase x% once every y months or year.

  5. We’ve to make same 24 UBI more valuable in USD/ETH units by focusing on max utility (other than exchanging UBI for USD/ETH) instead of changing accruing rate again & again to fit the USD/ETH market value or new narratives.



As much as I love and respect @0x57f908c42f5a0e5dbbd3c35a137cc242cf89add6_Ethereum —it’s all true, he convinced me about Ethereum back in 2016 when I was living in SF while starting DEF, and taught me about UBI :raised_hands:— we hold different views on this issue.

When I worked on the token contract, I made sure I asked absolutely everyone from Kleros and Democracy Earth about what the value of that parameter should be. 1 per hour, because of the reasons listed by @0xc0de4c0ffee, made plenty of sense:

  • accumulating a unit over an hour is better UX than dealing with fractions
  • 1 per hour was better than say 1 per day in order to dilute the premine

Predictability and stability I think really matters here. As @dogweather said, if we introduce any surprises (shannon information) changing the issuance rate… the market will bring wild swings in price… OTOH a market can easily coordinate a price against a predictable/stable issuance rate. (I come from Argentina and the issuance / inflation debate is deep in our culture).

That said, I will grant @0x57f908c42f5a0e5dbbd3c35a137cc242cf89add6_Ethereum that this is a sensitive topic and we should not rush at all regarding this very important variable. Locking decisions to soon is a bit risky imho (cc @Mads)

There are interesting ideas out there that we can explore as incentives… eg. decay the accrual rate over time based on some factor. I’m eager to hear from the community ideas that might help improve the tokenomics so far, and maybe locking this too soon could shut us away from a good idea.

But after 80 days since activation of the protocol… I have to say that 1 per hour turned out to be pretty good: we were always able to deliver > 100 dollars of UBI per month at any given time, that’s a lot for many people in the developing world… Hopefully we can grow that number as the token gains in utility and adoption.

TL;DR: I’m happy with 1 per hour


Not making decisions carries its own risks - apathy and missed opportunities. I think we would simply delay learning how the $UBI would function in the wild by delaying this decision. The lock is also not harder than that it could be reversed in case of objectively bad outcomes.

1 Like

Low participation rate and 50 / 50 split.

The participation is generally pretty low.
Anyway, the proposal has failed to pass to phase-3 because HIP-5 requires a majority for one choice - a split is not enough.

It can be retried at a later date.

Can the tag of the HIP be changed to signal that it is not active for discussion? Something like [on hold] or similar?