⚖️FCS Governance

FCS veto-based governance, voting power and cross-chain voting snapshots.

⚖️ FCS Governance

Overview

Frankencoin Share Token (FCS) is Frankencoin's canonical governance token. Holders build time-weighted voting power and can delegate it to other participants. Frankencoin uses a veto process rather than a ballot on every proposal. For proposals with a waiting period:

1. A participant submits a proposal and pays any applicable fee.

2. Qualified holders can veto it during the relevant period.

3. If no veto succeeds, the change can be enacted under the module's rules.

The Frankencoin thesis describes the general model. FCS is the holder-facing governance interface. Its contract exercises underlying FPS votes, and both FCS-based and direct legacy FPS actions are qualified against the same shared 1% quorum.

Taking part with FCS

1. Build or delegate votes. Acquire FCS through the share guide, then read your voting power. New tokens do not necessarily bring immediate votes. Use delegateVoteTo() to delegate to another participant; you retain your own ability to act.

2. Choose a proposal to examine. The governance application lists proposals and their state. Read the proposed module or parameter, chain, proposer and deadline. The notification bot can report indexed events, but does not cast vetoes.

3. Check qualification for the action. Read your internal FCS voting power, any valid delegation and the FCS contract's underlying quorum. On another chain, first complete the two vote synchronisations. Token balance alone is not an eligibility check.

4. Submit and confirm. Use the relevant module's proposal or veto operation while its timing conditions permit. After the transaction confirms, read the proposal's on-chain state. A discussion message, API response or wallet approval is not a proposal or veto transaction.

The module table below identifies the available actions. You do not need FCS votes to submit a new minter application, but qualified actions such as position vetoes and rate proposals require them.

Choose between acting and delegating

To act yourself, identify the proposal by its chain, module and proposal or position address. Read the proposed change and the time in which that module allows a veto. Include valid delegation helpers where the selected operation requires them, then check qualification for that action. Holding FCS does not by itself satisfy either voting threshold.

If another participant will examine proposals for you, choose their address and submit delegateVoteTo() with that delegate. After confirmation, read the delegation record. Delegation does not transfer your FCS, cast a veto or prevent you from acting yourself. On a target chain, also check the local delegation state after vote synchronisation, which can overwrite it.

For a proposal you submit, check its recorded parameters and activation conditions after confirmation. A proposal with a grace period is not active merely because its submission succeeded. Follow its state until it is vetoed or can be enacted under the module's rules. Rate-limit changes are an exception to a general waiting-period assumption: the audited CCIP design applies them immediately.

Immutable Modularity

The core contracts use separate modules for collateralised minting, savings, stablecoin conversion and cross-chain transfers. Parameters can change under their governance rules; an approved new module does not rewrite an old contract. Minting modules can mint, move and burn ZCHF. The application's governance page lists proposals and module state; there is no fixed count of active modules in this guide.

Community Consensus

Proposals can be discussed in the Frankencoin forum and Telegram group. Discussion does not replace the on-chain proposal or veto.

Proposal Submission

New collateral positions have their own proposal process. The following table describes the audited FCS governance modules, not every legacy deployment. Source: audit pp7 and 10.

Module or action	Who can act	Timing and fee
MinterGovernance.suggestMinter	Anyone may submit a minter application	Minimum 60-day application period and 1,200 ZCHF fee; up to 200 ZCHF replenishes the reward pool
denyMinter / denyPosition	Qualified FCS holders	Veto during the relevant proposal period
denyUnannouncedMinter	Anyone	Enforcement against a minter proposal bypassing the FCS announcement process; caller receives 10% of the reward pool
InterestGovernance	Qualified FCS holders on mainnet	Borrowing and savings rate proposals use parts per million and a seven-day grace period
CCIPGovernance	Qualified FCS holders	Configuration proposals follow CCIPAdmin rules; chain removal has a seven-day wait, but rate-limit changes apply immediately

The 60 days and 1,200 ZCHF apply to new minter applications, not position creation or interest-rate changes. Sidechains receive rate updates from mainnet; they have no local interest-rate proposal path in this design.

denyUnannouncedMinter does not detect every bypass. A direct legacy FPS veto can leave a stale announcement, as described in audit finding #028. Rate-limit increases remain immediate in the audited version; finding #025 discusses a future delay, not an implemented one. These mechanisms still depend on participants monitoring proposals.

Veto Process

FCS qualification

The caller, including valid delegation, needs more than 1% of voting power. Exactly 1% is not enough. This single quorum is defined once in Governance.sol (QUORUM = 100 basis points) and applied identically whether the check runs against FCS's own vote totals or against the underlying FPS1 vote totals for a direct legacy action. The audit's reviewed design instead gated the wrapper behind a separate, higher underlying-FPS quorum (at least 2% of FPS voting power) on top of the 1% FCS check; the shipped code replaced that two-tier gate with the single unified threshold.

The quorum and the binding threshold are different. FCS governance can become usable before the wrapper is binding. A high internal voting share alone does not prove that the wrapper can exercise an underlying veto.

Vote Accumulation

FCS votes grow with balance and average holding duration. An incoming balance does not carry the sender's holding time. Anyone can apply cap() to limit a particular holder's recorded duration to 365 days; this is not an automatic global cap. Direct FPS wrapping credits the holder's lost legacy votes, while ZCHF entry and WFPS migration provide no immediate carried votes.

delegateVoteTo() is transitive and non-subtractive. attack() lets a holder sacrifice votes to destroy an equal number of another holder's votes without changing token balances. The FCS voting reference defines these mechanisms.

Cross-Chain Governance

FCS holders can exercise governance on other chains without moving their shares off mainnet. The audited system needs two synchronisations before a holder can act on a target chain:

1. Send the wrapper's underlying FPS votes through GovernanceSender.pushVotes.

2. Send the individual holders' FCS votes through MainnetVotes.pushFPS2Votes to BridgedVotes on the target chain.

Select the target chain and holders to update, obtain the CCIP fee and submit each required synchronisation. Anyone can trigger these calls and pay the fee in the native asset or LINK. Track both messages to delivery and read the destination voting state before submitting a governance action. FCS tokens remain on mainnet in this design: vote snapshots, not tokens, cross the bridge.

Snapshots are not live mainnet balances. A selective sync can update total votes without updating every holder. A mainnet sync also overwrites local sidechain delegation for each included address. Old failed messages can later execute and overwrite a newer corrective sync; restoring state may require processing outstanding messages before sending fresh snapshots. CCIP delivery, message ordering and complete updates therefore affect destination qualification. Audit pp7–10 and finding #006, pp22–23.

Proposal monitoring

The veto design avoids a full ballot for uncontested proposals. Its operation still depends on holders examining proposals and acting within the applicable period. The audit's trust model assumes no malicious majority of internal FCS votes after binding. See governance failure modes.

Legacy FPS qualification

FPS still maintains its own underlying votes and quorum check; FCS does not globally replace that contract's rules. That quorum is the same shared 1% used by FCS-based actions, not a separate higher threshold. Direct FPS voting and the legacy holding-time example are documented in the underlying FPS reference. Existing holders can follow the migration guide to take part through FCS.