Frankencoin (ZCHF)

Frankencoin (ZCHF): How the Swiss franc stablecoin uses collateral, auctions, and veto governance

Frankencoin is an overcollateralized stablecoin designed to track the Swiss franc without relying on a conventional price oracle. Its model combines user-created debt positions, market-based liquidation auctions, an equity reserve, and a governance token whose holders can veto proposed changes.

What Frankencoin is designed to do

Frankencoin, represented by ZCHF, is an ERC-20 stablecoin intended to follow the value of the Swiss franc. The project does not describe ZCHF as a hard one-to-one fiat redemption claim. Instead, it relies on economic constraints, collateralization, minting costs, and market incentives to encourage trading near Swiss franc parity. The documentation states that every ZCHF in circulation must be backed by assets worth at least one ZCHF, although the quality and liquidity of that backing depend on the collateral types accepted by the system.

The intended users are broader than borrowers alone. ZCHF can be transferred as a digital Swiss franc-denominated asset, used in DeFi applications, or minted against approved collateral. The project documentation also presents payments and Swiss franc exposure as potential use cases, but those uses depend on wallets, exchanges, liquidity venues, and integrations outside the core token contract.

Collateralized minting without a conventional oracle

A user creates a position by depositing collateral and minting ZCHF against it. Each position has parameters such as a collateral asset, a minting limit, a liquidation price, a reserve contribution, and a challenge period. The position owner can repay ZCHF and withdraw collateral, subject to the rules encoded in the relevant contracts. The MintingHub acts as the system’s main module for managing these debt positions, while the ZCHF contract gives approved modules the authority to mint and burn tokens.

Instead of reading an external price feed to trigger liquidations, Frankencoin allows participants to challenge positions they believe are priced too aggressively. A challenge starts an auction that helps discover the collateral’s market value. The design changes what bidders receive around the critical price point, so the original minter cannot simply bid against their own collateral to create a misleading price. This oracle-free approach is a project-specific design choice, not proof that the system is free from market-data, liquidity, or execution risk.

How liquidation losses are allocated

If an auction succeeds below the position’s liquidation price, the proceeds are used to repay the position and reward the challenger. The position’s own reserve is used first to absorb a shortfall. If that reserve is insufficient, the system’s equity capital can take the loss, reducing the economic value of Frankencoin Pool Shares. The reserve documentation also describes a broader borrower reserve as an additional protection layer. This creates a seniority structure, but it does not eliminate the possibility that a sharp collateral decline or weak auction demand produces losses.

The liquidation mechanism depends on practical market conditions. Challengers must hold or obtain the collateral being challenged, and bidders must be willing to participate during the auction window. The documentation warns that collateral with very limited availability can weaken the challenge process because a position owner might control most of the relevant asset. The system therefore depends not only on smart-contract rules but also on sufficiently liquid and distributed collateral markets.

ZCHF, FPS, and the reserve system

Frankencoin has a second token called Frankencoin Pool Shares, or FPS. FPS represents a claim on the system’s equity reserve rather than a second form of payment money. Holders receive the economic upside from fees and liquidation profits, while also absorbing residual losses when borrower reserves and auction proceeds are insufficient. FPS therefore combines governance rights with a risk-bearing capital role similar to equity in the project’s own banking analogy.

The system’s reserve framework separates several forms of support, including stablecoins held in bridge contracts, reserves associated with borrowers, and capital supplied by FPS holders. This distinction matters because collateral deposited in individual borrowing positions is not the same as freely available reserve capital. A review of Frankencoin therefore needs to examine both outstanding ZCHF obligations and the composition, liquidity, and loss-absorbing capacity of the relevant reserves.

Veto governance and cross-chain operation

Frankencoin uses a veto-based governance process rather than a conventional majority vote for every change. A proposal is submitted with a fee and remains open during a defined veto period. FPS holders with more than 2% of accumulated voting power can veto it, and voting power depends partly on how long FPS has been held. The project says this is intended to make governance lightweight while giving qualified holders a way to block new collateral types, minting modules, or other system changes.

The contracts are described as immutable after deployment, but governance can approve additional modules with significant powers over ZCHF, including minting, moving, and burning functions. ZCHF is also deployed across multiple networks. The project states that FPS governance remains anchored on Ethereum mainnet, with voting information synchronized to other chains so that eligible veto rights can be exercised remotely. This architecture adds operational dependencies around bridges, message delivery, deployment configuration, and the accuracy of cross-chain state synchronization.

Security record and practical limitations

Frankencoin’s public materials identify several security reviews, including a ChainSecurity assessment and an earlier BlockBite report. The ChainSecurity report describes the reviewed contracts as non-upgradeable with limited privileged roles, but also records an unresolved concern about recovering from bridge failure. These reports are useful evidence of prior review, not a guarantee for the current deployment: audits are time-limited, cover specified code versions, and do not remove economic, governance, bridge, or integration risks.

For a newcomer, the main practical question is not simply whether ZCHF is labeled a stablecoin. It is whether the collateral accepted by the active minting modules can be valued and liquidated under stress, whether auction participants remain available, whether FPS equity is large and liquid enough to absorb losses, and whether the particular network version being used has reliable bridge and application support. ZCHF’s design reduces reliance on a conventional oracle, but replaces that dependency with a more involved combination of auctions, reserves, governance, and cross-chain infrastructure.

Key takeaways

• ZCHF is designed to track the Swiss franc through collateralization and incentives rather than a hard fiat redemption promise.
• Users mint ZCHF through collateralized positions managed by the MintingHub and related position contracts.
• Liquidation auctions are intended to discover collateral prices without a conventional external oracle.
• FPS is both a governance token and the system’s residual-loss-bearing equity layer.
• Governance uses a low-threshold veto model, while cross-chain deployments depend on synchronized governance and bridge infrastructure.
• Audits provide evidence of prior code review but do not remove collateral, auction, governance, bridge, or smart-contract risks.

Risks and open questions

• Collateral markets may be too shallow or concentrated for challenges and auctions to function efficiently during severe stress.
• A rapid fall in collateral value can exceed borrower reserves and reduce the value of FPS equity capital.
• The oracle-free design shifts risk toward auction participation, market liquidity, challenge timing, and execution conditions.
• Approved minting modules have powerful ZCHF permissions, so governance decisions and module implementation are material system risks.
• Cross-chain versions introduce bridge, message-delivery, deployment, and synchronization dependencies; prior audit material identified bridge-failure recovery as a concern.
• Public audits cover particular code versions and dates. They should not be treated as proof that every current contract, deployment, or integration is defect-free.