Need Opinions on onchain voting contract

I would like to program a coin voting / DAO governance structure entirely on chain, but I am running into some issues and need advice. It would be on something like gnosis/polygon so gas shouldn’t be an issue.

Governance can be split into 2 main functions – 1) Send a certain amount of tokens from the treasury to any address. 2) Call a function (ie, setParameters()) on one of our contracts. There should be some delay after a vote passes before either one happens. That’s all easy enough. Where I run into the issue is how to conduct coin voting in a decentralized manner on chain. Here are three possibilities and the drawbacks of each.

1) Past Snapshot Voting – Each token holder votes based on their balance at a certain block. Someone uploads a merkle root of the balances and then the contract checks when each vote is cast. The issue of course here is either a) The person uploading the merkle root has to be permissioned or b) anyone can upload the root, but there has to be some way to dispute it. AFAIK, there is no way for someone to prove a merkle root wrong in solidity since it does not have access to previous history.

2) Add Votes Continuously – Each user votes and the contract records them as having voted Y/N, how many votes they cast, and adds those votes to the total. We then release an opensource program that any user can run which can scan through all the votes and current token balances, and can notify the contract if there are any discrepancies. The contract checks the current balance and updates the running total.

3) Voting preference only – Users record their vote and preference, but not their number of votes. When the vote closes, the contract goes through, reads the current balance, and then adds them up. The issue here of course is that we may run out of gas in the block, so we may have to split them into batches of say, 100 votes. Then, someone needs to send a tx for every batch in order to finalize the election.

4) Auto-update of votes in transfer function – We could put some logic in the ERC721 transfer function to automatically update votes – but this would add some complexity/cost and also I think limit us to one concurrent proposal.

Of course, 2 and 3 seem vulnerable to a flashbots bundle like

1. Flash loan 1M
   
   1. Buy Tokens
      
   2. Record batch / update vote
      
   3. Sell tokens
      
   4. Repay loan.
      

3 might avoid this issue if we could guarantee to take up all the gas (or close) in a block, but that would require all batches being full I think.

Perhaps a multisig with the only purpose of uploading a merkle proof at a snapshot might be good. Still, I would rather make it completely decentralized if possible.

Any advice, or better yet existing code, would be highly appreciated.