Governance and transparency
See how proposals, voting, delays, execution, and public records constrain high-impact policy changes.
ZYNC has two governance surfaces. Space-local proposals and votes are implemented in the testnet Beta and use Points weight inside that Space. The separate network-governance model uses ZYNC and Base.
The ZYNC Governor and Timelock contracts are deployed on Base testnet, and the indexer mirrors their events. No public on-chain proposal or vote transaction surface is implemented yet. TON remains a peer day-one account and value rail, and Telegram cryptocurrency flows remain TON-only. The Base governance anchor does not make a person's Base address the canonical account or permit Base functionality inside the Telegram Mini App. A governed policy used by TON must be versioned and independently verifiable before the TON adapter acts on it.
A governed change should connect:
- a public proposal;
- the policy or configuration being changed;
- voting eligibility and quorum;
- a visible voting period;
- an execution delay;
- the final executed action;
- an audit record linking the result back to the proposal.
The planned network-governance baseline uses held ZYNC for governance weight. Paid memberships and lock duration do not increase voting power.
Transparency is more than publishing a vote total. Readers need the proposal text, timing, affected policy, outcome, and execution status.
Emergency controls, where they exist, need narrow scope, named authority, public after-action reporting, and no hidden expansion into ordinary governance.
Space-local proposal and vote flows are Beta on testnet. The public ZYNC-governance write flow remains Planned and still depends on approved policy and production deployment gates.