Towns Governance End-to-End Flow

Summary

Voting power

1. 1. Governance runs on Base. The Spaces, voting strategy, checkpoint registry, review strategy, and enactment record all live on Base.
2. 2. TOWNS voting power exists on two chains. A member’s total voting power combines delegated TOWNS on Base with delegated TOWNS on Ethereum.
3. 3. A permissioned publisher relays Ethereum state to Base. A Cowrie-managed publisher is responsible for reading the complete Ethereum delegation state. It signs that checkpoint and submits it to the onchain registry contract. The registry rejects stale, malformed, mismatched, or incorrectly signed checkpoint data.
4. 4. Each proposal fixes its electorate. At creation, the contracts record a Base block and timestamp. The publisher reconstructs the Ethereum state at that same time and binds it to the proposal. Votes then use that fixed Base and Ethereum voting power for the life of the proposal. This ensures that voting power is aggregated at the same point in time across both chains. The same mechanism can be extended to additional chains or voting-power criteria over time.

Lifecycle

1. 01

   Proposal submission

   A proposal references an ipfs:// metadata URI containing the decision and any actions it would authorize. The URI is content-addressed: changing the proposal document produces a different identifier. Cowrie binds the same metadata to every stage, so the proposal cannot change between submission and final passage. A member with at least 1 TOWNS of combined voting power can submit a Temp Check. A wallet holding the configured Node Operator NFT can bypass the Temp Check and submit directly to the Final Vote.

2. 02

   Temp Check

   The Temp Check begins with a parameter-configurable delay period that allows its cross-chain voting-power checkpoint to be finalized. Its voting period is also configurable and is currently set to five days for Towns. It passes when combined FOR voting power from Base and Ethereum reaches at least 5% of the total minted TOWNS supply recorded at proposal creation. Future emissions are therefore excluded. AGAINST and ABSTAIN votes do not affect this threshold. Upon passage, anyone may promote it to a linked Final Vote. The metadata is carried forward from the Temp Check, so the proposal contents cannot change between the Temp Check and Final Vote.

3. 03

   Final Vote

   The Final Vote uses the same configurable initial delay. Its voting period is also configurable and is currently set to seven days for Towns. It passes when FOR exceeds AGAINST and total participation reaches at least 10% of the total minted TOWNS supply recorded at proposal creation. Upon passage, anyone can move the proposal forward into the Rules Committee review period.

4. 04

   Rules Committee review

   The review period lasts three days and cannot be extended. During that period, the Rules Committee can revert the proposal with a recorded reason or affirm and enact it early through the normal Snapshot X execution path.

5. 05

   Final passage

   After review expires without a reversion, anyone may submit the transaction that completes the Snapshot X proposal. Committee affirmation invokes the same execution path atomically before the deadline. Either transaction records and emits final passage. For Towns, the governance contracts do not execute the proposal’s described external calls, though the architecture allows a timelock execution strategy to sit at the end of the pipeline.

FAQ

What if the Cowrie relayer stops working?

Monitoring is in place to alert Cowrie. If the relayer stops, Ethereum voting power stops updating. Once the latest checkpoint becomes stale, new proposals cannot be created. Any proposals currently in the pre-vote period cannot proceed to voting until their creation-time checkpoints are published. Late checkpoints reduce the usable voting time; in the worst case, a proposal can expire before voting ever opens. The lifecycle fails closed instead of using voting power captured at different times on Base and Ethereum.

The registry administrator can replace the trusted checkpoint signer and operate a replacement publisher without redeploying either Space.

Who are the permissioned actors, and what powers do they have?

• Administrator

  The admin can:

  • Choose the key trusted to sign checkpoints.
  • Change voting delays and durations.
  • Add or remove authenticators that control how proposals and votes enter a Space.
  • Add or remove voting strategies that calculate voting power.
  • Change the proposal-validation strategy that determines who may propose.
  • Upgrade the Space implementation.
  • Coordinate a Towns lifecycle-module replacement to change the execution strategies that define passage, review, and finalization.
• Checkpoint publisher: signs and publishes the cross-chain voting-power checkpoints accepted by the registry. This actor is responsible for relaying state from other chains to the chain containing the voting contracts.
• Rules Committee: can revert a passed Governance Proposal during review or positively affirm and enact it early. Its authority is time-limited and cannot extend the fixed deadline. If the committee takes no action or ceases operating, the review period expires on schedule and anyone can complete final passage. The committee cannot cause a failed vote to pass.
• Towns Node Operators: can bypass Temp Checks and submit a proposal directly to the Final Vote by proving ownership of a configured Node Operator NFT. They receive no additional voting or review power.

Promotion after a successful Temp Check, opening Rules Committee review, and completing final passage are permissionless and can be executed by any address once their onchain conditions are met.