Audit of the platform
This task has become relevant after several cases of the blockhain shutdown. They were caused by mistakes that hasn't been discovered since the early days of the platform. We believe such mistakes still exist and this situation endangers the main features of the blockchain - its continuance and immutability. Even couple of hours of shutdown leads to financial losses (not to mention reputational cost). We will conduct audit along with development, but it will be our priority at first.
Just FYI, this could go hand in hand with HackTheDex, and it would likely pay a much higher rate when you find actual bugs.
Changing the fee collection system
The most basic example will be the fee for cancelling of an order. If a user doesn't have enough funds, he cannot do this because the fee cannot be withheld from the order. We plan to fix this along with other issues that we will describe in a separate BSIP. Now we investigate how to implement this feature safely (e.g. there can be a situation when funds placed in the order are not sufficient to pay a fee - in that case it still won't be cancelled).
The main issue here is keeping the fee pool of a private asset funded. Any order can already be canceled if it contains enough to pay cancellation fee, because the user gets the balance from the order first, and then the fee is deducted. This only works e.g. with GATEWAY.BTC if the fee pool of the asset is funded. The only reason that you can't cancel orders in the BitShares UI without having the cancellation fee before is complicated frontend code, but no core issue.
Flexible settings of trading access keys
The idea that was discussed for a long time. The BitShares is a trading platform in the first place. However, it lacks flexible settings of keys that allow to provide access to trading to a third-party, not exposing active keys at the same time. Of course, there can be duct tape solutions already, but we need something more solid.
I assume you mean publishing release 4 to mainnet with BSIP-40 here (which provides that among many other use cases)? Or did you have something else in mind?
Non-LTM referral & membership
Creation of the classic on-chain referral system. It will allow to invite new users without extra costs and unnecessary headache (unlike the implementation in the majority of other projects). What can be more useful than the growth of the user base?
Can you elaborate what you mean with "the classic referral system"?
At first we expect direct payments without an escrow.
Will you denote your worker in some BitAsset, FIAT or BTS?