One concern I haven't resolved is anti cheat. The approach I described makes every player the Server of their own universe, meaning with a tiny database update they can generate a god fleet to send to someone's universe. I can encrypt the database for multiplayer, but if someone wants to cheat, it won't be difficult. Which is one reason why the host of the player needs to be able to kick another player and their fleets out, and lock the wormhole for that player. I haven't thought about how to stop smaller, difficult-to-notice cheats though. Like, if nobody is nearby and you add 100k duranium to Luna or free fuel to a stranded fleet, how is anyone going to notice you're giving yourself small advantages?
For a start, if you want to leave SM available for those that want it, as a means to resolve issues, etc. I'd keep a running log of every SM action taken, alert any other party that connects that there are actions in the SM only log, so there's no hiding it. Allow any connecting party to view the SM action list for every other party. If they're cheating via SM, it'll be in there with date/time, game time, sm action, target entity. If they've had an issue, discussed it, and decided to resolve it via SM, it'll be in there, but they'll both know to expect it.
As for external db edits, there's two problems. Knowing there has been a change, and knowing what was changed. In the interests of leaving the players able to correct minor issues on their own, it might be worth leaving the database reasonably accessible, kind of like steve has with aurora. That would require a means to give accountability then, so it can't be hidden from others, and if at all possible, they can know the who/what/where/when of it, and leave why to the players to sort out and discuss.
For detection, its probably enough to simply hash the database immediately on writing it out and saving that, or when loading and comparing it to what was saved. You'll know they changed it, but not what was changed.
For what, write the database twice. Once encrypted and kept secure, the other as normal. When the hash doesn't match on load, you can decrypt the secure copy, and compare. You now know what changed.
If you really want to be transparent, have maximal accountability, and minimise the bellyache that could be caused by implementing a fix via edit, having a means to show the state up to several turns before and after in game would be ideal. Keep the encrypted database and the delta, you've got the log to point them at exactly what differs, and the information to show them. They can verify for themselves its a harmless fix, or free minerals just because. Something akin to, this unit was moved, show unit? show them, and show the before/after positions on a button toggle. Ditto for minerals, or whatever. This planet's minerals changed by this much, want to see?
Game decides to eat your fancy new battle cruiser when you hit launch....just because it didn't have enough titanium in its diet? If you have at least the previous two databases, you can show that it was in production, finished and didn't exist.....so you SM'd a replacement, and only that.
It comes at a cost of some free intel for the other guy because they'd need to see the in production ship from a previous turn to know the game owed you a ship, but your game goes on, because they are satisfied you weren't cheating. There are steps that can be taken to mitigate shared intel, but that's getting quite beyond the scope of cheat prevention and into making it a more player friendly system.
Its not perfect. But I think it prevents the free lunch entirely, and alerts others you've tried. How much you try to let quasar speak for them about what changed as a perfectly neutral observer, your call, and I doubt its worth it for the first iteration of multiplayer when you get that far. That's something that makes sense as removing a limitation that multi imposed, the database could not be fairly edited to fix issues without having take the other guy at his word that it was a justified edit.