Crown is not PoW anymore, moved to MNPoS. You can stake it by setting up Masternodes or Systemnodes. First coin out there (as far as my knowledge goes) where nodes produce blocks

https://medium.com/crownplatform/crown-masternode-and-sytemnode-proof-of-stake-consensus-system-mnpos-e6780ef534b3

Seems that Coinwarz has not updated the information on their site, current Crown client is 0.13.2

Crown Platform Development update for May 2019 is here

First off, an apology: we aren’t able to release v0.13.4 by 6 May. Although the current release candidate solves the slow sync problem, fixes the display of immature rewards, fixes the address labels problem, and (added bonus) reduces the memory requirement, it has proved to be a bit unstable. It will be released as soon as the instability is resolved.

Now that MN-PoS is operational we are looking forward to the next developments in the evolution of the Crown platform. In order of arrival, and scale, they are:

Trezor integration
NFT framework
Codebase update


Trezor integration
This is an exciting development which brings the security of a hardware wallet to Crown users and offers the possibility in future to start masternodes and systemnodes without requiring a full desktop wallet.

It involves several components, some of which are completed and others which are nearly complete. The completed components are the new address prefixes in Crown v0.13 (“Jade”) and update of the Electrum-Crown wallet to understand the new address format. Changes to Bitcore to understand the new address formats are in progress and could be ready within two weeks. Bitcore will provide an Insight explorer which allows access to information in the Crown blockchain. The final component is the actual Trezor integration. Our target release date is June 2019.

NFT framework
This will extend the use-cases for the Crown platform and allow users to develop their own applications. Non-fungible tokens can be used in myriad ways. The initial framework version is expected in the “Emerald” release and will provide registration and timestamping facilities. One of the most basic applications of NFTs is recording proof-of-existence and we already have people interested in developing more complex applications. To facilitate this we aim to provide developer documentation ahead of the release, expected in testnet by July 2019.
Further development of the NFT framework will be guided by user feedback on the initial release.

Codebase update
Crown is based on Bitcoin core v0.10 and v0.11. In computing and crypto terms this is ancient. Bitcoin v0.18 was released on 2 May 2019.
Updating the codebase is a major undertaking with the principal benefit of making future maintenance easier. It will also enhance security and provide access to additional features. There is no estimated completion date yet but the project will take several months.

https://medium.com/crownplatform/development-update-may-2019-a53cc2c7eb55

Dear crown community!
I read the intro on https://crown.tech/learn-more-about-crown and I didn't find any special stuff.
Could someone tell me as easy as possible about crown progress with links please?
P.S. I know another similar platform - shiftnrg but they already have working dapps, but haven't masternodes unfortunately.
Cheer!

Recommended CROWN update v0.13.4.0

We are pleased to announce the release of Crown v0.13.4.0. This is a recommended update.


Although you can continue to run v0.13.2, unless you have already taken steps to mitigate the increased RAM and CPU usage, you almost certainly will hit problems further down the line. We recommend everyone update at their earliest convenience.

v0.13.4.0 is a recommended update for all users

What does it include?

It was originally planned to include three fixes but actually includes four and some enhancements:

The long awaited fix to the v0.13 sync problem.
Following the v0.13 update, a number of users experienced very severe performance problems with syncing the blockchain. A number of workarounds were published, which successfully circumvented the problem for most of those users. Others continued to experience unacceptably slow syncing. Ashot and presstab have worked hard to identify and resolve the issue.
With the new update, everyone with a part-way decent internet connection should be able to complete a full sync in less than 4 hours.

Incorrect display of rewards on the wallet summary screen.
Rewards were showing as mature (available to spend and stake) before they actually were.
Fresh masternode and systemnode rewards, and staking rewards now show as “Immature” in the wallet summary screen until they receive the required 100 confirmations.

Address labels.
Ashot has worked his magic in the wallet and old labels display correctly with no intervention from the user.

CPU and memory usage.
It became apparent during development that there was a bigger and more pressing problem than any of the preceding three. Nodes and wallets were using much more RAM and CPU than in v0.12.5.3. Depending on the hardware they were running on, nodes could exhaust the available RAM and crash themselves or even the VPS after a couple of days. Painstaking research showed the increase to be related to code hardening against one of the PoS attack vectors. Presstab reworked the code so that it still provides the same protection but at much lower resource cost.

Installer enhancements.
While waiting for the code fixes in v0.13.4 a number of workarounds for the sync and resource usage were deployed. Although they should no longer be required it was thought beneficial to provide easy access to them through the installation/update script. So the script now includes options to add the watchdog script to a new or existing node, to sync a node or wallet using the bootstrap, and to install a pipeline build.

I’m sold, how do I upgrade?
As always, the new release is a drop-in replacement. Essentially, make a backup of your wallet.dat, shutdown your wallet and node(s), replace the executables and restart. The details vary from platform to platform and environment.

Hosted node
If you use a hosted masternode/systemnode service they should take care of the node update for you. Since this is not a mandatory update you might need to ask them, but given the resource savings to be made by upgrading it’s likely they’ll be way ahead of you! You can update your node(s) before or after your wallet; the order is unimportant.

QT wallet
Restart the wallet and it should prompt you to download the update.

Self hosted node (linux) or a wallet
If you are already using the watchdog script you should disable it before upgrading (otherwise it could restart the node at an inopportune moment). See below.
If you’re not interested in the watchdog and bootstrap simply use the one-liner to update a masternode or systemnode. Log on to your server and run
sudo apt-get install curl -y && curl -s https://raw.githubusercontent.com/Crowndev/crowncoin/master/scripts/crown-server-install.sh | bash -s

All environments
The network protocol version has not changed so it isn’t necessary to issue start-alias commands for masternodes or systemnodes if you have already upgraded to v0.13.2.0

What about the watchdog and bootstrap thingies?
The installation/update script has new options which could still be useful in certain circumstances. If you want to take advantage of them, we recommend you download the latest version of the script and run it directly (doing so gives you the most flexibility, but if that sounds too complicated see below).

Download the installer
You can use curl or wget. The following example uses curl. Put the installer somewhere in your path (/usr/local/bin is recommended) and make sure it is executable.
sudo curl -ousr/local/bin/crown-server-install.sh https://raw.githubusercontent.com/Crowndev/crowncoin/master/scripts/crown-server-install.sh
sudo chmod +xusr/local/bin/crown-server-install.sh

watchdog
The watchdog as originally published ran every 15 minutes and did two things:
Check if crownd is running, start if it is isn’t.
Check free memory and restart crownd if it is “too low”.
If you are already using the watchdog it won’t do any harm to continue running it after the upgrade, but you should disable the cron entry for the duration of the upgrade. Use the command
crontab -e and comment out the watchdog entry by putting a hash sign (#) at the start of the line. Uncomment the line (by removing the hash sign) after upgrading.

The watchdog could still be useful after the upgrade. It is very unlikely you would need the memory checking. However, making sure your node is running every 15 minutes isn’t a bad thing (but don’t use the watchdog in conjunction with systemd or any other automatic process starter/monitoring system).

The installer has a new option, -w followed by a number 1 or 2 which corresponds exactly with the two actions described above. If you want to add the watchdog to an existing instance at the same time as upgrading then the command to use is
crown-server-install.sh -w 1
or, if you want to use the free memory checking as well
crown-server-install.sh -w 2

bootstrap
Syncing performance in the v0.13.4 update is vastly improved. Pretty much everyone should be able to sync a new node across the network, from scratch, in less than four hours. With a good internet connection, we saw several such syncs complete in less than two hours during testing.
There may still be times when syncing with the bootstrap is useful so the installer now has the option to use it. Most VPSs have a good internet connection but your local connection may not be as fast or reliable. We anticipate some wallet installations might benefit from syncing with the bootstrap, which can be done using the -b option. For example
crown-server-install.sh -c -b

The -c option indicates this is a new wallet installation (-w is already used for the watchdog). This example will ensure your system is updated, download the release package and the latest bootstrap, create swap space if you don’t have any, write a new crown.conf, update your firewall, install the release package, unzip the bootstrap into the datadir and start the daemon.

wait, there’s more!
Unless told otherwise the installer will fetch the latest release package from our Github mirror. There may be times when you want to use some other version, specifically a test version from a Gitlab pipeline build. A number of community members helped test this version before release and we’re grateful for their assistance. If you’d like to get involved and help with testing in future please get in touch via the #contributor-general channel in Discord.

Use the -j option to specify a pipeline build to install or update to. For example
crown-server-install.sh -j 6114

The installer has a number of other options. They are mostly additive although there are some mutually exclusive combinations (for instance you can’t specify both -m for a masternode and -s for a systemnode in a single invocation). You could combine all the options we’ve seen so far here, like
crown-server-install.sh -j 6114 -c -b -w 1
to install a pipeline build as a wallet, sync with the bootstrap and enable the watchdog (level 1).

We plan to publish another article soon describing the installer in more detail.

Wrapping up
Thank you to everyone who has upgraded to v0.13.2 for your patience while we dealt with the glitches and performance issues. We recommend you update at your earliest convenience.
There are still a number of v0.12.5.x nodes and wallets which have not upgraded. Although the node count is down about 20% the network hasn’t really missed them but they have been missing out on both node rewards and staking rewards. We hope these fixes will encourage their owners to upgrade those nodes and rejoin the network.

If you have any questions or issues with the upgrade or want to know more or even just chat about Crown, please contact us in Discord or Telegram.

https://medium.com/crownplatform/recommended-update-v0-13-4-0-6791cb0599a8

I have analyzed your project, it is realistic and seems to be performing well. Can you confirm when the next division of annual percentages will take place in 2020 or 2021?

That's exactly what it is! I couldn't have described it better

Attention masternode owners

It’s time to vote!

Being a masternode owner isn’t just about earning a passive income. With great rewards comes great responsibility. Masternode owners are responsible for enacting the Crown Decentralised Governance Proposal system which decides the future direction of the Crown project, and allocates funds from the superblock to the current proposals.

If you need a reminder of what the CDGP system is about please take a look at the governance section of the Crown website, and familiarise yourself with the superblock calendar and the voting system.

TL;DR
It is crucially important that you exercise your duty to vote in the monthly superblock “election”.
The next superblock is at block 2,419,200 which is estimated to occur at about 07:20 UTC on 17 June 2019. However, voting closes 2880 blocks (about 2 days) before that but your masternode must remain online until the actual superblock for your vote(s) to count.
Please go and vote now!

Why?
Last month, in superblock 2,376,000 the submitted proposals asked for a combined total amount of Crown which exceeded the available funds. The proposal with the largest ask received the smallest number of votes and consequently, although it passed, it did not get funded. This put continued platform development in jeopardy. Also, fewer than 20% of the enabled masternodes actually voted.
That’s right, the majority of masternode owners abdicated their responsibility and left it up to a minority of a subset of the Crown community to decide how the project should progress and which proposals to fund.

This month, for superblock 2,419,200 the submitted proposals again ask for a combined total amount of Crown which exceeds the superblock maximum of 54,000 CRW. It is possible that there will be some additional proposals submitted for this superblock which will further increase the competition for the limited funds available. Almost inevitably that means some proposals will fail to be funded, even if they pass (a proposal passes when the number of Yes votes exceeds the number of No votes by at least 10% of the number of enabled masternodes).
At the time of writing, only about 30% of masternodes have voted in this superblock.
We need all masternode owners to carefully review the submitted proposals and vote according to their interpretation of the best interests of the project.

Each proposal contains a link to a detailed description of what it entails, how much funding is sought, who is asking for it and doing the work, and the benefits it will bring. Please take the time to review all the proposals and to consider (among other things)

- the total available budget
- the individual amounts requested
- the other proposals amounts requested
- the priorities of the project
- the impact of each proposal on those priorities if it is funded and if it isn’t funded
- just passing may not be sufficient for a proposal to be funded

Hint: it would be a really good thing if the development and infrastructure proposals passed!

Where to find the proposals?
You can see a pretty colour overview of the active proposals at crowncentral.net:

An enhanced proposal view but you can’t vote directly here
You can also see the submitted proposals directly in your QT wallet in the Voting tab of the Masternodes page:

The voting tab in the QT wallet
Most importantly, you can also vote for them here. But before voting, please take time to click on the URL for each proposal to read the details. Some of the descriptions can be found in the Crown forum:

Proposal descriptions in the Crown forum
but proposal owners can put the description anywhere (Google docs is another popular location).
The description should include essentials like who is making the proposal, how much they’re asking and what the community gets in return. There should also be contact details so if you have any questions about the proposal you can contact the proposer and seek clarification or offer comments and feedback.

Questions and comments are positively encouraged because they increase participation and help build the community. If you vote No on a proposal it would be really helpful to the proposer if you let them know why you voted that way. You can ask questions and leave comments in the #proposals channel in Discord.

How to vote

Each proposal includes instructions on how to cast your vote. There are two cryptic looking lines of the form

How To Vote YES: mnbudget vote-many 3c67369ab31786ab1bff83c3634a71eb3b9b8983260d1f97c0e664bc741cdb4f yes
How To Vote NO: mnbudget vote-many 3c67369ab31786ab1bff83c3634a71eb3b9b8983260d1f97c0e664bc741cdb4f no

which are what you need to know if you’re going to vote using the command line interface or the debug console of the QT wallet. You can also vote directly from the Voting tab in the QT GUI. Whichever method you’re going to use, your wallet must be unlocked before you can vote.
To vote using the QT GUI, click on a proposal to highlight it and then click the appropriate vote-many button. The wallet will respond with a confirmation request window:

After voting you should get a result window similar to:

Due to a bug in the QT wallet, votes don’t always register on the first attempt. If you don’t get a result window like this, you need to vote again.
Important. You can vote more than once for any proposal but only your last vote before the voting window closes counts. So you can change your mind on a proposal if you want to.

Remember: this superblock is over-full. It is probable that not every proposal which passes will get funded. If passing proposals don’t get funded there is a possibility that some superblock funds will remain unallocated and be wasted (as happened last month). One of your responsibilities as a masternode owner is to ensure funds are allocated in the best interests of the project. You may want to change one or more of your votes to make that happen.

Please vote as soon as possible.
Please also check again before the voting window closes (around 07:20 UTC on 15 June) because circumstances could have changed and you may want to vote again.

So far only about 30% of masternodes have voted. Let’s see if we can double that number over this coming weekend.

https://medium.com/crownplatform/attention-masternode-owners-4c15040f285

I'm willing to admit what you say but 3h of confirmation 100 or 150 confirmation for CROWN on = 2h or 3h30 MN exemple it's much very  toooooooo long even for POS example CLOAK or VIOG or ExSolution coins 5 confirmation and everyone is happy.

How can the mass adopt if we have to wait X confirmation with 107 years?