First cab off the rank, of course. The account balances accumulated in the period between the genesis block and the public release of steemit.com for each account will be totaled, and subtracted from the current balances of these accounts.
This has now been started: https://steemit.com/calibrae/@elfspice/calibrae-strategy-change-opt-in-rather-than-algorithmically-determined-opt-out
This balance will also remove the simple steem, and SBD, all calculated at the VESTS equivalent at the time of the snapshot. If this happens to make the premined accounts have zero balance, that's just bad luck, I guess. This process will be entirely nonprejudicial except against the not-public nature of these initially mined Steem Power contracts.
The removed premined VESTS will be set as the initial rewards pool so there is rewards to be assigned from day one, instead of the 7 days of accumulating that will happen otherwise. This will of course mean a few weeks of huge payouts. This is of course an incentive to migrate, but also, a way to keep the total amount of currency same across the migration.
This also further simplifies the process of creating the snapshot, and in fact eliminates not just SBD, but the Steem. The way Steem works is there is an underlying primary currency called VESTS.
These are going to be renamed JUICE (as in, like nectar), and the deposit contract, aka Steem Power, will be called, simply, Stake. So, when you come to use your account on the new chain, you will see your vested Stake on one hand, and all the SBD and Steem will be converted to VESTS and that is the number you will see, with the ticker JUICE.
Simplification is both technically better, as well as better for UX (user experience).
Without SBD, witnesses do not need to use their Active key to set a price feed. There is no SBD interest rate or bias to set. It makes this aspect of witness operating so much simpler.
The user experience is also simplified, and users can just see their reward JUICE directly labeled, and there can be a configuration to choose to either see it as Raw JUICE, or converted into other currencies using price feeds, when there is exchanges.
Next, the option to receive liquid rewards is removed. Users can either accept rewards, or refuse them. The field is excessively large, also, so this cuts some crap out of the size of the post data size. It will just be zero or nonzero, meaning yes or no to payout.
Stake is drawn down by a much simpler scheme: at the time one enables power down, 1% every subsequent 24 hours, of the remaining Stake is converted to Juice. This eliminates weekly price cycles and improves the ability to seize trading opportunities. The algorithm also prevents the account from drawing down completely. In 365 days, all else remaining unchanged, the power down gets to 2.5% of the original amount.
This is of great benefit to investors, because they know that rewards cannot be rapidly dumped, which means the price movements cannot have these scissor-sharp slices, which can be especially brutal when traders are on margin. At least, it greatly reduces this possibility, and it also ensures that the market cap will steadily grow, reflecting the valuation against the issuance rate that dilutes the value in paying out rewards.
It is simple to eliminate this possibility, another example of a change that is a simple delete. Many of the proposed changes are just deletes. This will naturally improve the maintainability of the codebase, and improve user understanding of the platform. Yes, of course people can vote for themselves with other accounts, but that was never the point of this. It's just not cool to vote on yourself. Only the premined whales could really fully argue against this, because their whole angle is milking the public pool.
The post itself will be counted as a self vote, and thus, also, the curation reward split thus must be raised to 50/50. In effect, this will likely make little difference to the real split, but it satisfies the issue about self voting - by posting, you vote.
This one is simple. When an account posts update_witness and becomes active, its witness votes are not counted, and instead a single vote on one's own witness is totaled instead. This eliminates the possibility of collusion between witnesses, and the leverage of large stake accounts that could seek to dictate a mutual vote that can corrupt the witness pool - if one account, or group, can control the actions of more than 10 witnesses, they can arbitrarily veto hardforks.
Instead of infrequent, many changes at a time hardforks, it will be proposed that once a month, change ideas are collated, then subjected to a vote using comments to signify the options for a given hardfork, and then once the reward payout occurs, the developers implement the single change, and then create a new version tag, and the witnesses then either upgrade, or not.
This will also be facilitated by simplifying the update so that witnesses can just run a single command that compiles the new build automatically, signifying their support for the change, or they do not invoke it. Eventually, it should be possible to have this trigger by a special type of transaction made by the witness, that automatically builds the new version, hands-free, without SSH shennanigans. Witness operation should not be a complex job.
This is a high priority change, because left unaddressed, this will lead back to the eventual problem with RPC nodes down the track. In fact, it may make sense to even create a new operation mode called 'ledger only' or something like this, so that the RPC node only processes transfers, vesting, and the like, and does not even parse the votes or posts at all.
These two changes will permit Calibrae to not have issues with exchanges like are plaguing steem right now.
By taking a total of all account reputation scores, and then scaling them to 0-100% factor on rewards allocation, it would be possible to enable the community to, via downvotes, punish those who use their stake in a negative way, as discussed in 
I had already been considering this change to be an essential component of how one can use a voting system to monetise development work, but as 
It is very important to consider, that this is both a financial and social network system. Both factors should equally weigh in everything.
I think it should be obvious that many of the premined accounts, especially and notably 
To deal with these scoundrel (s) I propose that the precise vests that are in question, get tracked through the whole pathway. Not the votes they assign, just the actual original VESTS tied up in that SP.
This may be a complicated algorithtm to process, and may be the biggest hold-up in getting the chain sanitised. Other alternatives, have too much human judgement factor in them. It is not possible to alter the distortion of the distribution that came about from their voting power being (ab)used, however, not all of that voting was bad.
So I will suggest that the sanitisation process will need to include a 'follow the money' process, and I think that it should be simple enough to simply say that the first amount, up to the premined vests, amounts transferred out of those accounts, be subtracted from the destination accounts, and so on, with the flux properly mapped out and before this subtraction is applied, it be put to vote via a post whether the calculations have been correct.
This will suck the air out of all of 
I invite everyone who is interested in being part of this fork, or even just to make your opinion known, to comment on any element of these proposals, and that the results of the non-frivolous, non-malicious commentary will help set the work order.
