Ok, most VPS crashed at some point of time, our local wallets crashed on average after some hours as well. So it is not an issue within the GUI but within the core client itself (GUI builds just on-top). It is caused by one of the parallel threads.

Lets outline the positive aspects first:
-> the mining integration (atleast what is implemented yet) is functional
-> in contrast to the previous update the processing of transactions and integration in blockchain works well as far as I can see.
-> the chain is close to be in sync (see next aspect)
-> invalid messages at certain points of time will not be processed from any node (guards and message checks looks really good now)

What wents wrong at the moment:
-> VPS and clients are crashing from time to time, blockchain is out of sync
      -->from what I can tell: the async is this time caused by the crashed VPS and not due to buggy code directly linked to chain sync but investigation needs some time
     -->that is an improvement from latest versions where chain asyncs occured with functional clients

What can improve the client:
->find and eliminate all crashes in core client. That increases stability and might get the chain in sync at any point of time. Just restarted 3 VPS and we get again 4 official VPS back in sync automatically! That is really a good improvement. The resync/replace mechanism works well as it seems.

We will follow this roadmap:
->rescan the whole code, especially the critical sections, guards and threads, review all delete ([]) and new ([])
->publish large parts of the code in our wiki
->deliver next update, including: bugfix, full operational block explorer search (there was an vector.clear() missing so it shows only one transaction due to boundary checks ->already fixed for next version, allow search for txid, blockid), more functional mining process, allow more than one miner to connect to the client (that is possible, but both miners would mine at the same value ->different seed offsets needed), interest calculation process
->Make final thoughts about API interface, make wiki page especially for potential exchanges to see what the interface will look like.
->Set up UDP server for API remote interface communication, maybe RPC implementation as well
->buy more VPS to set up proxy<->backnet idea (see latest changelog) ->efficient security against early DDoS after official launch
->Unix version will not be delivered before launch  since we already have enough work to compete with. Working on this if we have time or if someone from the community is eager to do this after we fully release the source code (possibly some days after launch). Partial integration of UNIX is already within the code.
->marketplace integration will be targeted after launch as already communicated
->due to the latest problems we must delay the launch. We cannot and we do not want to launch a buggy product. At least the nodes must be able to run some days without any chain async or crash. We want to set a new ETA that is somewhat challenging, but realistic. Delaying an ETA to the next ETA to the next ... is not a good style as well. I am sorry for the delay. I hope you can understand that and see the need to have a stable product at launch.
Besides: This gives exchanges some time to adapt to eXocoin. We would like to have at least one exchange one week after the launch.
->develope GUI  miner using OpenCL early May
->validate all mail applications (small c++ program to download bitcointalkmember list already programmed)


Timeline:
-> next udpate: Hard to tell. The last updates ETAs have been postponed always at least some hours up to 1-2days. That is not a good style but it is difficult to predict. I would say we can deliver an update on monday or tuesday.
-> launch ETA: sunday, 11th May



I hope you understand our changes and see that it is not reasonable to launch eXocoin before May. The new time can be used to make the product more stable, implement the essential missing features and adapt to exchanges.

Thanks and best regards
eXocoin team


#edit: it should use quite exactly 100% CPU on one core from blockstart till found a result. Until the next block it should stay at 0%. With V0.59 you can launch more instances (for one processor one). But that is not essential. The CPU miner will be somewhat a demonstrational purpose as long as we do not have a GUI miner.