What “On-chain Votes” Means
In BERT, a vote is an on-chain state change, not a signed message stored in an external service. The voter sends a real transaction, and contract logic decides whether it is valid. If checks fail, transaction reverts and no vote is recorded.
This gives strong auditability: all accepted votes, timestamps, and outcomes are visible in blockchain state and events.
Vote Transaction Flow
Standard path is: user prepares amount -> wallet signs transaction -> vote(roundId, ideaId, amount) is executed in VotingSystem -> stake transfer path is routed through FundingPool -> vote totals update.
Because this is transaction-based, users pay gas for execution attempts. Failed checks still consume gas, so UI should validate obvious constraints early.
Validation Rules (Contract-side)
A vote must satisfy all of the following protocol rules: round exists, round is active, current time is inside voting window, voter has not voted in this round, amount is at least minStake, and idea belongs to the round.
Additional anti-abuse constraints include self-vote prohibition and max-voters-per-idea limit (when configured). These checks are enforced by contract and cannot be bypassed by custom frontend clients.
Round Settlement & Finality
After round deadline, anyone can call endVotingRound(roundId). The system computes winner by highest votes, updates proposal statuses, and triggers downstream progression/reputation logic according to configured rules.
Settlement is deterministic from chain state. If two interfaces show different visuals, canonical truth is contract data.
On-chain vs Off-chain Voting
On-chain voting has direct execution guarantees and full traceability, but costs gas and depends on chain availability. Off-chain voting is cheaper and faster for signaling, but execution still needs trusted bridge logic or separate on-chain confirmation.
BERT governance-critical decisions are designed to be on-chain so treasury-impacting outcomes are enforceable without external trust assumptions.
Security Notes
Operators should monitor failed vote transactions, unusual stake concentration, and parameter changes affecting vote economics. During incidents, pause flow (pause -> diagnose -> patch -> verify -> unpause) remains the default control policy.