We just shipped three fixes to the MoonVote backend that harden the tokenomics layer. Here’s what changed and why.

1. Burn transactions are now verified on-chain (Critical)

Previously, when you created a post, the backend checked that you submitted a burn transaction hash — but it never actually verified that transaction on-chain. In theory, someone could have submitted a fake hash and created posts without burning any MOON.

Now the backend fetches the transaction receipt from Arbitrum, decodes the PostBurn event logs, and verifies:

  • The transaction actually succeeded
  • It came from the MoonActions contract
  • The burner address matches your wallet
  • The burn amount is at least 1 MOON
  • The same transaction hash can’t be reused for multiple posts

This is the core sybil resistance mechanism, so getting it right matters. If you’ve been posting legitimately, nothing changes for you.

2. Tip nonces now sync with on-chain state (High)

The tipping system uses sequential nonces to prevent replay attacks. The backend was only tracking nonces in its own database, but the smart contract has its own nonce counter on-chain. If the bridge service restarted or tips were settled through other means, these could drift apart, causing tips to fail with “invalid nonce” errors.

The nonce endpoint now reads both the database and the on-chain MoonActions.nonces() value, returning whichever is higher. If the RPC is temporarily unavailable, it falls back to the database value gracefully.

3. Tip settler no longer fails entire batches (High)

Tips are settled on-chain in batches. If one tip in a batch had a problem — say the tipper revoked their token approval or ran out of MOON between signing and settlement — the entire batch would revert and every tip in it would be marked as failed, even the valid ones.

The settler now runs pre-flight checks on each tip before including it in a batch: verifying the tipper’s balance, allowance, nonce, and deadline. Tips that fail pre-flight are skipped individually with a specific error message. If a batch still reverts unexpectedly, the settler bisects it to find the bad tip and settles the rest.

All three fixes are live now. The post creation flow, tipping, and wallet auth all work exactly the same from the user side — these are purely backend hardening changes. The bridge service also picks up the settler improvements automatically.

If you run into any issues, let us know in the General community.