A better restore database logic
Using a "sync id" for every cards/transactions is a good idea and it's used in many "directory database" (like in Microsoft's Active Directory) because makes sync'ing very strong and hardly missing a change.
But this choice has a "drawback" when you need to restore a database!!
The procedure explained in https://safeincloud.uservoice.com/knowledgebase/articles/425234-how-to-rollback-a-database-to-a-point-in-time is almost unusable when, like me, you have 3 computers and a phone sharing the database and you may NOT have all of them available at the same time! Not doing that ends in "merging" data so effectively voiding the restore...
The Restore action should mark the database as "mandatory" and must be restored on each devices forcing a replace without merging.
On Microsoft's Active Directory this is done using a special procedure that force the transactions ID to be greater that the "greatest available".