Beg to differ. Any liquidity is a benefit to the project. Remember, it took a bubble in BTC to bring in the traders. A bubble is evidence of the lack of liquidity. Traders are the only source of the kind of liquidity that will be expected by future vendors who agree to accept Decred as payment. Immediate conversion at spot price will be expected with no slippage. That takes tremendous liquidity - the kind that comes with a group or groups making the market. With no innate value (discounted future earnings), current investors in Decred (us) are betting on the both successful development that leads to ease-of-use and the liquidity that I mention. Big investors or uninvested vendors will need this liquidity up front. Thus, the chicken/egg scenario, that is so common with would-be crypto-currency, is again the case. Waiting for liquidity to develop on its own is probably not a very good plan. On the other hand, it is also not an immediate need. We will need the Devs to release some noteworthy apps. Then we will need some generic publicity. A pretty good bubble will then likely ensue. Edit: As @davecgh points out, ASICs will help to secure the network. A little bubble can help with this, as well.

Remember Adam, only half the coins staked, on average, vote within a month. Some will take up to six months to vote and provide a return. Still, I agree that it is an almost irresistible deal at these prices.

It would be cool to see real time and historic statistics on this (way beyond my scope if I'm wondering about 50 Decred.) Made me think of how this simple formula is a measure of liquidity and possibly centralisation as well. Powerful.

I'm thinking 50% chance a ticket votes at 28 days, so some sooner, some later, a Gaussian curve where both the apex and average fall on 28 days. So the late return tickets may be offset by the early return tickets allowing one to use the mean for simple return calculations. I suspect the distribution may be non-normal though, something not quite as simple. Getting off topic, but a useful discussion I think.

Yeah, not sure about the math/stats either. Also must consider stake reinvestment and distribution of price paid. The calculation would be interesting, for sure. Maybe a mathematician is in the community?

A mathematician is indeed in the community. However, it's not a Gaussian curve at all. It's completely random. I'm not sure if the data exists for this, but if you were to do a histogram of the time taken for each ticket to vote it should be more or less flat across all time frames. If you have a look in the PoS forum, I've done the math a couple of times. The 50% after 28 days comes from the following formula: A = 1 - (1 - P) ^ N Where A is the chance of a ticket voting after N periods (blocks) and P is the probability of a ticket being chosen each block (also note that ~5 tickets are chosen per block). If you plug the numbers in you actually get about 61% over 28 days given the current state of the network and 99.1% before expiry. It is important to note that a ticket is NOT more or less likely to be chosen based on the time it has spent in the pool. A ticket 1 block old has the the same chance of being chosen as a ticket 10 000 blocks old.

That seems right. But, can you work in the likely monthly return? Seems that you would need to estimate average prices paid as well as for reinvestment. With this return number, we can project where prices may need to go to encourage greater liquidity on the exchanges.

I did a rough simulation, monthly return looked like Gaussian curve. A bit improved version is running at the moment, shall give a bit better extimation.

So let's see... I'll do it with a 30 day month. That gives a single ticket a vote chance of 63.1%. Standard tx fee is 0.05DCR and reward is currently 1.8532DCR. Stake at this point is averaging about 11DCR per ticket. That means that the profit per ticket is 1.8032DCR with an initial investment of 11DCR. So we have an average monthly return of 1.8032 / 11 * 0.631 = 10.34% So that's for a single ticket and assuming no replacement. I've built a small model to look at how many tickets vote each month given that the user has 100 tickets in the pool: This is a histogram of 1000 simulated months of PoS voting with 100 tickets. X axis is the number of tickets chosen per month, y is how often that number was chosen. It's not normal (I could do a QQ plot but it's late), there's some skew to the right, but it's close enough. So we can see that with 100 tickets in the pool each block, (the model assumes that the pool size and ticket cost is constant and removed tickets are replaced each block) you can expect between 90 and 120 will vote each month (let's assume a non-weighted average of 115). This gives a return of (1.8032 * 115) / (11 * 100) = 18.8% / month. Now there's a lot of factors here that will change these numbers, especially given the fluctuation in stake prices, but looking at my own returns I'd say it's in the right ballpark.