Index

General Information
Part A: Information about the offeror or the person seeking admission to trading
Part B: Information about the issuer, if different from the offeror or person seeking admission to trading
Part C: Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Part D: Information about the crypto-asset project
Part E: Information about the offer to the public of crypto-assets or their admission to trading
Part F: Information about the crypto-assets
Part G: Information on the rights and obligations attached to the crypto-assets
Part H: Information on the underlying technology
Part I: Information on the risks
Part J: Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts

2026-05-29

This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union.
The person seeking admission to trading of the crypto-asset is solely responsible for the content of this crypto-asset white paper.

This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.

The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid.

FALSE

The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council or the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.

Warning
This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other documents pursuant to the applicable national law.
This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.

Frankencoin (ZCHF) is a crypto-asset without an identifiable issuer, thereby excluded from the scope of Title II, III or IV of the MiCA Regulation by Recital 22.

ZCHF is used within the Frankencoin Protocol. ZCHF operates as an ERC-20 token on Ethereum Mainnet and is implemented through a decentralised collateralised debt position mechanism.

Under this structure, users deposit eligible crypto-assets as collateral in order to mint ZCHF, subject to protocol-defined collateralisation requirements. The system is overcollateralised and operates through transparent smart-contract rules governing issuance, repayment, and liquidation. These mechanisms do not constitute a guarantee of value, do not provide holders with a contractual right of redemption at par against an issuer.

As a result of the above mechanisms, there are decentralised economic incentives that make it economically attractive to repay debt positions and recover collateral if ZCHF trades below CHF parity, or to mint more ZCHF if it trades above CHF parity. While this could suggest the asset references an official currency in the sense of MiCA Article 3(1)(7), the definition of “electronic money” in article 2(2) of Directive 2009/110/EC, as established in article 4(25) of Directive 2015/2366 and article 2(4)((C) of the MiCA Regulation, defines electronic money as claims against issuers. Therefore, we interpret that ZCHF’s lack of identifiable issuer, absence of claims against any parties and nonexistence of redemption mechanics, makes ZCHF a “crypto-asset other than asset-referenced tokens and e-money tokens”. Irrespective, the question of the asset’s classification is superfluous as the asset is excluded from the application of Titles II, III and IV of MiCA due to the recital 22 provisions for assets without an identifiable issuer

Not applicable as 05 is false

As an asset without an identifiable issuer, ZCHF is excluded by MiCA’s recital 22 from the application of Titles II, III and IV and the admission to trading requirements regulated therein, inclusive of white paper requirements. However, in order to support crypto-asset trading platforms in streamlining their admission to trading processes, and to reduce the operational burden and compliance costs associated to listing processes, MiCA Crypto Alliance OpCo Limited is voluntarily submitting a white paper for ZCHF as a best practice despite the inapplicability of the requirement. In this context, this white paper is specifically targeted for admission to trading to the Kraken trading platform.

MiCA Crypto Alliance Opco Limited

2025-11-19

984500CEB5773O38LE40

+44(7441)903166

submissions@micaalliance.com

Preparation and submission white papers under the EU Markets in Crypto Assets Regulation.

The main object of the company is to own, manage and administer property of any kind whether belonging to the company or not. The secondary object of the company is to hold shares and, or equity in other companies.

TRUE

Not applicable

The entity was incorporated in November 2025 in Malta and therefore does have a limited financial history.

Since incorporation, the entity’s financial condition is developing in line with the scaling of its operational activities in the MiCA-related activity and technology services sector. The entity is generating revenue from MiCA white paper preparation, ESG data disclosures, XBRL reporting services, and related MiCA support for CASPs and blockchain-based projects.

Since its establishment, the entity has maintained sufficient financial resources of USD 2,000,000 to support its ongoing operations and development activities.

The development of the business has been driven by increasing demand for MiCA compliance services, including white paper drafting, ESG methodology development, and regulatory submission support. In addition, the entity has developed auxiliary tools and initiatives, including a white paper tracking tool aligned with the ESMA registry of notified MiCA white papers. This tool supports market transparency and ecosystem monitoring and has contributed to increased engagement with market participants and stakeholders, thereby indirectly supporting business development activities and client outreach within the MiCA compliance sector.

This has resulted in a progressive increase in client engagements, drafting of more than 60 MiCA white papers, and expansion of ESG data analysis activities covering more than 1,200 token datasets.

In addition, the entity has expanded its operational ecosystem through partnerships with legal, financial, and blockchain industry participants, supporting the scaling of its service offering and market presence.

Given the recent incorporation date, historical financial information is limited. However, the entity’s financial position is currently supported by available capital resources and ongoing service activity, with no material adverse changes identified since establishment.

TRUE

Frankencoin

Not applicable as DTI is provided in F.13.

Not applicable as DTI is provided in F.13.

Frankencoin is a decentralised protocol for the creation, use, and management of ZCHF.

ZCHF is generated through a collateralised minting mechanism under which users may mint ZCHF against eligible collateral through smart contracts, subject to the applicable protocol rules. The primary use cases for ZCHF are payments, Swiss-franc-denominated transactions, store of wealth use cases and participation in collateralised minting mechanisms within the Frankencoin Protocol.

The project operates through transparent smart-contract mechanisms, including collateralised positions, repayment, and liquidation processes. The protocol also includes governance arrangements involving Frankencoin Pool Shares (FPS), including veto-based governance for certain proposals relating to collateral types or other methods of bringing ZCHF into circulation, and saving rate adjustments.

ZCHF tokens are created when users deposit eligible crypto-assets as collateral into smart contracts and mint ZCHF against such collateral, subject to predefined collateralisation requirements and applicable protocol parameters. The protocol operates on an over-collateralised basis and incorporates liquidation mechanisms intended to support market-based price stability in relation to the Swiss franc.

Eligible collateral assets must satisfy the technical and operational requirements established by the Frankencoin Protocol and the applicable smart-contract parameters, as described in H.3.

The initial collateral deposited when opening a position must be at least equal to the specified minimum collateral. A new position must start with at least 5,000 ZCHF worth of collateral.

Challenges and auctions are supported in respect of collateralised positions, and the contract includes handling for cases where collateral cannot be returned to a challenger due to blacklist or transfer restrictions.

In addition to enabling payments and storage of wealth through ZCHF, the Frankencoin Protocol offers a collateralised ZCHF minting mechanism that may be described as borrowing in exchange for an interest. A part of this interest is routed to ZCHF holders via a native savings mechanism through which holders may deposit tokens into the protocol's Savings module and earn a return denominated in ZCHF.

FALSE

Not applicable

Past milestones

Since 2023, Frankencoin has enabled on-chain Swiss-franc-denominated transactions. As at 4 May 2026, the public Frankencoin website states that Frankencoin has been deployed on eight different blockchains.

By 2024, the Frankencoin project had published public explanatory materials concerning the Frankencoin Association, FPS, oracle-free design, decentralisation, and Swiss-franc-denominated on-chain use cases through its Substack publication.

On 4 September 2025, ZCHF/USDT trading was scheduled to open on MEXC following an initial listing announcement published on 3 September 2025.

On 23 September 2025, public social-media materials described an integration involving Frankencoin, Zeal Wallet, Gnosis Pay, and Mt Pelerin, including CHF/ZCHF on- and off-ramp functionality, yield access through Zeal, and card spending through Gnosis Pay.

As at 2025 and 2026, the project’s GitHub discussions show continued governance and collateral-related activity, including proposals relating to collateral types, savings-module upgrades, and multichain infrastructure. Public GitHub discussions include a proposal for an upgraded savings module dated 22 May 2025, a multichain infrastructure proposal dated 23 June 2025, and collateral-related proposals dated 2025 and 2026.

Future milestones

As of 4 May 2026, public GitHub discussions show ongoing proposals and community activity relating to additional collateral types, liquidity infrastructure, multichain infrastructure, and savings-module upgrades.

No central allocation of proceeds from a public offer, issuer-controlled token sale, or centrally managed project budget has been identified for ZCHF. The Frankencoin Protocol allocates resources through smart-contract-based mechanisms, collateralised positions, and the Frankencoin reserve structure rather than through a central issuer allocation.

The Frankencoin system includes ZCHF and FPS. FPS provide proportional exposure to the equity reserve pool of the Frankencoin system. The equity reserve pool is funded with ZCHF deposits made in order to obtain FPS in return, ZCHF fees paid to the protocol, and liquidation surpluses arising from challenged positions. FPS represent proportional ownership of the equity reserve pool. FPS holders whose accumulated voting weight reaches at least 2% of the total accumulated votes may veto governance proposals, including new minting module proposals, position proposals, and savings rate changes, as described in H.3. This pool has two purposes. First, a part of the reserve pool funds the savings module described in H.3, as determined by the savings rate. Second, the equity reserve pool is used to cover losses arising from liquidation events in which collateral value falls below the amount of ZCHF borrowed against it. FPS may be redeemed for ZCHF once the applicable 90-day holding period following minting has elapsed.

Not applicable

By admitting ZCHF to trading, holders may benefit from access to additional liquidity for buying and selling ZCHF. Admission to trading may support the ability of users, borrowers, liquidity providers, and other ecosystem participants to acquire or dispose of ZCHF through an organised trading venue, subject to market conditions, available order-book depth, applicable fees, and platform-specific access requirements

Payward Global Solutions Limited (Kraken)

PGSL

Admission to trading of ZCHF is sought on Kraken. Subject to admission to trading, access to the trading platform would be available through Kraken’s web platform, mobile application, and, where supported, Kraken Pro. Users would be required to access the relevant Kraken portal, create or maintain an account, complete any applicable verification requirements, and comply with Kraken’s terms, supported jurisdiction requirements, fees, and applicable legal and regulatory restrictions.

The trading platforms where the admission to trading is sought do not involve any costs related to investors’ access.

Not applicable

Not applicable

Ireland

Ireland

Crypto-asset excluded from Titles II, III and IV of Regulation (EU) 2023/1114 due to the lack of an identifiable issuer, in accordance with the Regulation’s recital 22.

ZCHF is a decentralised, overcollateralised crypto-asset issued within the Frankencoin protocol. Its primary functionalities are enabling payments and storing value, and decentralised, borrowing-like minting of ZCHF itself against crypto-asset collateral, and subsequent use of ZCHF for payments and value holding.

ZCHF may be used for Swiss-franc-denominated payments through compatible applications and services, including payment applications, debit card integrations, IBAN-related integrations, wallets, bridges, and other third-party tools. The availability of such services depends on the relevant third-party provider, supported networks, and applicable legal and technical requirements.

ZCHF may be acquired with fiat currency or other crypto-assets where supported by exchanges, decentralised trading venues, wallet providers, or other service providers. Such acquisition methods are external to the core protocol and may be subject to user eligibility, fees, liquidity, sanctions screening, anti-money laundering and counter-terrorist financing controls, and jurisdictional restrictions.

ZCHF may be “borrowed” through the Frankencoin protocol by depositing eligible crypto-assets as collateral into collateralised positions. The owner of a position may deposit collateral and mint ZCHF up to the applicable limit defined by the relevant liquidation parameters.

The Frankencoin protocol further includes collateralised minting and savings functionality implemented through protocol smart contracts. Users may mint ZCHF against eligible collateral in accordance with applicable protocol parameters, while holders of ZCHF may deposit ZCHF into protocol-supported savings mechanisms.

Applicable savings and interest rates are determined through the protocol governance process and may be modified in accordance with the applicable governance procedures. Any yield or return generated through the savings mechanisms is variable, protocol-dependent and not guaranteed.

Developers and businesses may integrate Frankencoin functionality into applications and financial services through the available developer resources and APIs, including access to protocol data relating to ZCHF, FPS, minter contracts, approved collateral types, positions, minting activity, transfers, and other ecosystem information.

Not applicable

ZCHF is generated through an overcollateralisation mechanism whereby users lock eligible crypto-assets as collateral in smart contracts in order to mint new tokens. The protocol enforces collateralisation requirements and may trigger automated liquidation of positions that fall below predefined thresholds.

The token is transferable on supported blockchain networks and can be used as a means of exchange or for value transfer between participants. Ownership of ZCHF is represented by control over cryptographic private keys associated with a blockchain address.

ZCHF does not confer a claim against an identifiable issuer and does not provide a legally enforceable right of redemption at par value in Swiss francs. Its value is influenced by collateralisation mechanisms, protocol rules, and market conditions.

Transactions involving ZCHF are executed and recorded on the underlying distributed ledger and are generally irreversible once confirmed. The functioning of the token relies on smart contracts that govern issuance, transfers, and collateral management.

ZCHF is not covered by investor compensation schemes or deposit guarantee schemes.

Not applicable

Not applicable

2026-06-27

2026-06-26

Not applicable as there is no identifiable issuer.

English

1GS8GZGXV

2R50HSCVB

FALSE

TRUE

FALSE

Not applicable as ZCHF does not confer any contractual, proprietary, or redemption rights against the issuer.

ZCHF is issued against overcollateralised positions within the protocol. Positions may be unwound by repaying ZCHF, which results in the release of the underlying collateral. The value of ZCHF may be realised through such mechanisms or through transactions on secondary markets, subject to market conditions and liquidity.

Holders are responsible for the secure management of their private keys. Loss or compromise of private keys may result in permanent loss of access to ZCHF.

Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.

Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.

Not applicable

FALSE

FALSE

Not applicable

This admission to trading does not outline any restrictions on the transferability of the crypto-assets.

TRUE

The supply of ZCHF is adjusted mostly through an overcollateralised issuance and repayment mechanism within the Frankencoin protocol, and secondarily through swap mechanisms against other Swiss-franc-linked assets. ZCHF tokens are created when users deposit collateral into smart contracts and mint ZCHF against such collateral — subject to predefined collateralisation requirements —, or when other Swiss-franc-referencing digital assets are converted into ZCHF through 1:1 bridge or redemption mechanisms.

Collateralisation requirements are defined through the protocol’s position mechanism rather than through a universal predefined list of eligible collateral assets or a minimum collateralisation percentage. As long as the technical criteria for acceptable collateral described in H.3 are met, participants may freely create ‘positions’ specifying the applicable issuance, collateral, liquidation, and other operational parameters (typically — though not necessarily in the case of 1:1 swap positions — including a collateral asset, liquidation price, minting cap, interest rate, and maturity date in the case of overcollateralised positions), which may then be challenged by other participants. A newly proposed position enters a governance veto window (the initialisation period) of at least 3 days, during which qualified FPS holders may permanently deny the position. If not denied, the position becomes active and the owner may mint ZCHF. Separately, any active position (or even a position still in its initialisation period) may be challenged at any time; the auction duration for any such challenge is a configurable parameter set by the position creator, ranging from minutes to up to two weeks depending on collateral liquidity , after which the position owner may deposit collateral into their position to mint ZCHF, or other users may clone the active position — creating their own cloned position inheriting the parent's parameters — to mint ZCHF immediately without a further initialisation period.

ZCHF tokens are removed from circulation when users repay their outstanding positions, resulting in the burning of the repaid tokens. Positions may close once outstanding ZCHF has been repaid and collateral withdrawn, upon expiry of the position term, or through liquidation where collateral no longer satisfies the applicable collateralisation requirements.

Where the market price of ZCHF deviates from its intended reference value, market participants may be incentivised to mint additional tokens or to repay and burn tokens, depending on prevailing market conditions. Liquidation mechanisms apply through a challenge-and-auction process open to any market participant who believes a position's collateral no longer adequately supports the outstanding ZCHF obligation. A challenger deposits an equivalent amount of the collateral and initiates an auction; if the auction result confirms the position is undercollateralised, the position is settled and the corresponding ZCHF is removed from circulation. This mechanism operates without external price oracles or automatic ratio-based triggers.

As of the date of writing this white paper, the web page https://app.frankencoin.com/mint identifies the following active positions within the Frankencoin protocol to support minting of ZCHF against collateral: Boss Info AG, Coinbase Wrapped BTC, Curve DAO Token, Gnosis Token, Switzerland AG C1 Shares SHA, Liquid Staked ETH, Paxos Gold, RealUnit Shares, SPDR S&P 500 ETF (Ondo Tokenized), Wrapped BTC, Wrapped Ether, Wrapped liquid staked Ether 2.0, Tether Gold, and Staked yBOLD. In addition, there are 1:1 swap/redeem positions relating to Allunity Swiss Franc and VNX Franc. In other words, ZCHF may also be redeemed against two other Swiss-franc-referencing tokens without loan-to-value-based collateralisation mechanics.

TRUE

The token value protection framework of Frankencoin coincides with the supply adjustment mechanisms described in G.13. As described above, the value of ZCHF is primarily supported by an overcollateralisation framework. ZCHF tokens are primarily issued through collateralised smart-contract positions, although the protocol also supports bridge-based issuance modules. While the protocol does not impose a universal overcollateralisation requirement, overcollateralisation is strongly incentivised as a position creator must put capital at risk to earn income from minting ZCHF against a position, and the capital is more likely to be lost through challenge, liquidation or bad debt if the position is insufficiently collateralised.

Where the value of collateral falls below the required thresholds of each individual position, liquidation mechanisms may be applied to the relevant positions in order to maintain sufficient collateral backing. These liquidation mechanisms, together with reserve capital committed to absorb potential losses, position-specific minting limits and risk parameters defined for each position, and certain 1:1 swap or redemption arrangements relating to other Swiss-franc-referencing assets, form part of the value protection framework for ZCHF.

FALSE

There is no written legal agreement governing the legal rights or obligations associated with holding the crypto-asset between token-holders and an identifiable issuer.

In a context where an identifiable issuer cannot be established, no identifiable issuer can be designated as entering into a contractual relationship with token-holders in relation to the crypto-asset.

Accordingly, no single governing law or competent jurisdiction can be predetermined for disputes relating specifically to the crypto-asset itself. The determination of applicable law and jurisdiction would instead depend on the nature of the specific legal relationship in question, including any involvement of identifiable third parties such as crypto-asset service providers, project developers, or the asset interface operators.

Such determination would be made in accordance with applicable private international law rules and mandatory legal provisions, including consumer protection rules where relevant.

There is no written legal agreement governing the legal rights or obligations associated with holding the crypto-asset between token-holders and an identifiable issuer.

In a context where an identifiable issuer cannot be established, no identifiable issuer can be designated as entering into a contractual relationship with token-holders in relation to the crypto-asset.

Accordingly, no single governing law or competent jurisdiction can be predetermined for disputes relating specifically to the crypto-asset itself. The determination of applicable law and jurisdiction would instead depend on the nature of the specific legal relationship in question, including any involvement of identifiable third parties such as crypto-asset service providers, project developers, or the asset interface operators.

Such determination would be made in accordance with applicable private international law rules and mandatory legal provisions, including consumer protection rules where relevant.

Not applicable as DTI is provided in F.13

Networking

The Frankencoin protocol operates on the Ethereum mainnet and interfaces with clients through standard Ethereum JSON-RPC. Users interact with the system directly through compatible wallets and the official web application at https://app.frankencoin.com. Transaction submission, state queries and contract interactions all follow the Ethereum application interface standard. ZCHF is also deployed on Polygon, Arbitrum, Optimism, Base, Avalanche, Gnosis and Sonic through the cross-chain transfer module, with the same contract address 0xD4dD9e2F021BB459D5A5f6c24C12fE09c5D45553 on each of those networks.

Serialisation

Transactions follow the Ethereum transaction format, including EIP-1559 fee market transactions. Smart contract interactions use ABI-encoded calldata consistent with the Ethereum ABI specification. The ZCHF contract implements ERC-20 (EIP-20) for token transfer and approval. The FPS contract additionally implements vote accumulation logic through a time-weighted holdings mechanism recorded on-chain.

Cryptography and key formats

Accounts on Ethereum use secp256k1 key pairs with Keccak-256 address derivation. ZCHF ownership is represented by control over a private key associated with an Ethereum address. The token contracts use standard Solidity constructs, and all core deployed contracts are immutable, meaning once deployed, they cannot be altered.

Ledger

ZCHF is maintained as an ERC-20 token on Ethereum mainnet at contract address 0xB58E61C3098d85632Df34EecfB899A1Ed80921cB. The associated governance token, FPS, is deployed at 0x1bA26788dfDe592fec8bcB0Eaff472a42BE341B2. Both contracts are deployed on the Ethereum mainnet, and their state, including balances, minting permissions, reserve holdings and vote accumulation, forms part of the Ethereum state, committed to the Ethereum blockchain through normal Ethereum block production.

Token standards

ZCHF implements the ERC-20 standard. FPS implements ERC-20 with additional governance logic: vote weight is calculated by multiplying an address's FPS balance by the duration for which those tokens have been continuously held, rewarding long-term participation and making flash-loan-based governance attacks ineffective. Any address with at least 2 per cent of total accumulated votes may exercise a veto on pending governance proposals in a single transaction.

Cross-chain transfer

ZCHF can be transferred between Ethereum mainnet and the supported networks through the Chainlink Cross-Chain Interoperability Protocol (CCIP) bridge, audited by ChainSecurity. The CCIP bridge maintains synchronisation of token supply and state between chains. Vote accumulation for governance purposes is anchored exclusively on Ethereum mainnet; FPS holders may synchronise their vote count to other chains using the built-in sync function in order to exercise veto rights on those chains.

Architecture

The Frankencoin system consists of a set of immutable smart contracts on Ethereum mainnet. The ZCHF and FPS token contracts serve as the foundation. ZCHF has a modular minting architecture in which any proposed smart contract that survives the FPS holder veto period may be granted the minter role, enabling them to mint and burn ZCHF without restriction from the token contract itself, subject only to the logic encoded in each module. The approved minting modules in the system are the MintingHub, which governs all collateralised debt positions; the StablecoinBridge, which facilitates 1:1 issuance against other CHF stablecoins; the PositionRoller, which enables flash-loan-based position refinancing, and the Savings module, which distributes interest to ZCHF holders.

Collateralised debt positions

A position is a debt exposure to a specific collateral asset created and registered by the MintingHub. New position contracts are deployed by the PositionFactory contract, which the MintingHub calls internally when a user opens a new position. Users interact with the MintingHub directly; the PositionFactory operates transparently in the background as the deployment mechanism. Each position belongs to one owner, whose ownership is transferable. The owner deposits collateral and may mint ZCHF up to a limit defined by a liquidation price they specify. When ZCHF is minted from a position, the proceeds are divided into three parts: the usable amount sent to the position owner, a minter reserve withheld within the equity contract and returned upon repayment, and an upfront non-refundable interest fee collected by the reserve pool.

Technical collateral requirements

Collateral requirements are defined in the smart contract MintingHub.openPosition(). It enforces basic ERC-20 compatibility (including a requirement that failed transfers revert and decimal limits), initial collateral sufficiency, decimal limits, initial collateral sufficiency, a 5,000 ZCHF minimum liquidation value, and a 1,000 ZCHF opening fee. In addition to these technical criteria, broader economic criteria are discussed by the community at https://github.com/Frankencoin-ZCHF/FrankenCoin/discussions/45, including that acceptable collateral should be fungible, free from fundamental transfer restrictions, possess considerable free float, have an externally assessable value, and not be prone to extreme “long tail events”, among other considerations. However, these broader requirements are enforced socially and economically through the initialisation period, veto rights, and challenge-auction mechanism, rather than through hard-coded technical restrictions.

Oracle-free liquidation through auctions

The system does not depend on external price oracles. Position soundness is instead enforced through a challenge and auction mechanism open to any market participant. A challenger who believes a position's liquidation price is below the market value of the collateral deposits an equivalent amount of the collateral asset and initiates an auction. The auction uses a mechanism that prevents manipulative bidding by the position owner: bids below the liquidation price compete for the challenger's collateral, whilst bids above the liquidation price result in the bidder receiving the position owner's collateral. This design makes price manipulation economically prohibitive. If the highest bid at auction end falls below the liquidation price, the challenge is successful: the position's minter reserve is dissolved, proceeds are distributed to settle the position and reward the challenger at a 2% rate, and any shortfall is absorbed by the equity reserve.

Reserve structure

The Frankencoin reserve has three components: stablecoins locked in the bridge contracts, minter reserves withheld from each active position, and equity capital held in the FPS contract. The equity capital is exclusively owned by FPS holders. The FPS pricing mechanism is based on the continuous capital corporation model: the market capitalisation of all FPS in circulation is set at three times the equity capital at all times. Anyone may contribute equity capital by minting new FPS at this price, and FPS may be redeemed for a proportional share of the equity capital after a minimum holding period of 90 days. FPS holders absorb residual risk from position liquidations and benefit from minting fees and liquidation surpluses, analogous to the shareholders of a bank.

Savings module

The Savings module is a governance-approved minting contract that permits ZCHF holders to deposit tokens and earn interest funded from the system's equity pool. Interest is funded from the system's equity pool and distributed at a rate set through the protocol's governance process, which permits FPS holders to propose and enact rate adjustments subject to a seven-day veto window.

Deposited ZCHF is fully segregated and attributable to its owner at all times; it is not lent out or otherwise transferred within the system, and unlike minter reserves, it cannot be accessed to cover system losses. A delay of three days applies before interest begins to accrue on a deposit, intended to discourage transactional use. Interest is calculated on the principal amount only; there is no compounding. Interest rate changes are subject to the standard governance veto process with a seven-day enactment window.

The Savings module is accessible through the official protocol application at https://app.frankencoin.com/savings.

Dependencies

All contracts are written in Solidity and deployed on Ethereum mainnet. The system uses no external oracle dependencies. Cross-chain functionality relies on the Chainlink CCIP infrastructure. The official application frontend is maintained at https://app.frankencoin.com. Source code is publicly available at https://github.com/Frankencoin-ZCHF.

An emergency governance module, CCIPAdmin (deployed at 0x2527ec458c863073a303CF0a362Bf78aDD5dFEf8 on Ethereum mainnet), enables FPS holders to enact an emergency cut-off of cross-chain bridge flows through swift governance action in the event of a detected bridge exploit or anomalous cross-chain minting activity. This function is not currently exposed in the official frontend and must be invoked directly through a tool such as Etherscan.

ZCHF does not operate an independent consensus mechanism. As an ERC-20 token on Ethereum, it inherits Ethereum's proof-of-stake consensus for all transaction ordering and finality on mainnet.

Ethereum validators stake ETH and are assigned block proposal and attestation duties. Ethereum time is organised into 12-second slots and 32-slot epochs. One validator is randomly selected as block proposer per slot; committees of validators attest to the validity of the proposed block. Finality is established once two consecutive checkpoint epochs each receive attestations from at least two-thirds of total staked ETH. Reverting a finalised block would require the slashing of the relevant validator stakes, making such reversion economically prohibitive. On networks other than Ethereum mainnet where ZCHF is deployed, the applicable consensus mechanism of that network governs transaction ordering and finality. (ethereum.org/en/developers/docs/consensus-mechanisms/pos/)

The Frankencoin governance process operates above the consensus layer through the veto mechanism described in H.3, and does not itself constitute a consensus mechanism.

Minting fees

When a user mints ZCHF against collateral, an upfront non-refundable interest fee is charged and retained by the equity reserve. The interest rate and reserve requirement applicable to each position are defined at the time the position is opened. The fee is calculated at the defined annual rate applied to the minted amount for the remaining duration of the position. This fee structure rewards FPS holders, who bear residual risk, and is designed to sustain the solvency of the equity reserve.

Challenger rewards

Challengers who successfully initiate an auction that concludes with the highest bid below the position's liquidation price receive a 2% reward on the challenged collateral value denominated in ZCHF. This incentive compensates challengers for the capital at risk during the auction period and is designed to ensure that unsound positions are identified and liquidated promptly.

Governance proposal fees

Proposing a new minting module or submitting a governance proposal requires payment of a fee of 1,000 ZCHF. This fee is retained by the system regardless of whether the proposal passes or is vetoed, and serves to deter spam proposals.

FPS incentives

FPS holders receive a share of protocol income from minting fees and liquidation surpluses through automatic adjustment of the FPS price. They also bear residual losses if liquidation proceeds are insufficient to cover outstanding obligations. The minimum holding period of 90 days before FPS can be redeemed from the protocol reduces incentives for short-term speculative participation in governance.

Savings rate

The savings module distributes interest to depositors from the system's equity pool at a rate set through governance. The savings rate and borrow rate are independent parameters. Proposed rate changes can be enacted after seven days without a veto.

Ethereum gas fees

All transactions on Ethereum mainnet require ETH for gas. Transaction costs reflect prevailing Ethereum gas prices and are independent of the Frankencoin protocol. On other supported networks, the applicable network's transaction fee model applies.

FALSE

TRUE

BlockBite Security Audit: February 2023

• Object: All Solidity contracts in the Frankencoin repository at commit 0db42977, covering the ZCHF token, FPS, MintingHub, StablecoinBridge and associated test files.
• Results: 2 high, 2 medium, 6 low, and several informational findings. The two high-severity findings identified a calculation error preventing position repayment and a missing position registration check that could allow unrestricted minting and drainage of challenge funds.
• Actions: All high-severity findings were fixed prior to mainnet deployment at the referenced commits. Medium and low-severity issues were addressed or formally acknowledged in accordance with the client's governance guidelines.

Code4rena Competitive Audit: April 2023

• Object: The full Frankencoin smart contract suite submitted to a public competitive audit pool over a one-week period with a $60,500 USDC bounty.
• Results: Multiple findings submitted by competitive auditors covering position challenge mechanics, price manipulation vectors and edge cases in auction logic. The most significant finding identified a scenario in which a challenge could be initiated and averted within the same block, enabling a colluding challenger and bidder to earn a discount on the collateral. The Frankencoin team confirmed this as the most important issue identified during the audit.
• Actions: Mitigations were implemented, including a rule preventing a challenge from being both started and averted in the same block.

ChainSecurity Audit: Core Contracts, October 2023

• Object: The Frankencoin system's core smart contracts, focusing on asset solvency, functional correctness and access control.
• Results: Functional correctness and access control rated high. Asset solvency identified as improvable, specifically noting the absence of a recovery mechanism in the event of bridge failure. No trusted roles beyond those inherent to the design were identified. Contracts confirmed as non-upgradeable.
• Actions: Findings were documented. The bridge failure recovery limitation was noted as a known design property rather than a remediable defect. Overall assessment: satisfactory level of security.

ChainSecurity Audit: v2024 Extensions

• Object: The v2024 protocol extensions comprising the updated MintingHub with variable interest rates, the PositionRoller enabling flashloan-based position refinancing, and the Savings module.
• Results: Two functional correctness findings. The new liquidation mechanism could interfere with the existing one, and the minimum collateral requirement for positions was not enforced in certain circumstances. A further finding identified that bad debt was not correctly accounted for in the forceSale function.
• Actions: Functional correctness findings were resolved. Overall assessment: high level of security. No additional trusted roles were introduced relative to the original system.

ChainSecurity Audit: CCIP Bridge

• Object: The Chainlink CCIP cross-chain bridge enabling ZCHF transfers between Ethereum mainnet and supported Layer 2 and sidechain networks.
• Results: A wrong assertion that could have led to loss of data in cross-chain state synchronisation was identified and corrected. Caveats regarding out-of-order execution and partial data transfers in cross-chain message handling were noted.
• Actions: The wrong assertion was corrected. Overall assessment: good level of security.

CHF/EUR exchange rate risk

ZCHF is designed to track the Swiss franc. However, EU holders measure portfolio value in euro, and the EUR/CHF exchange rate is independent of ZCHF's protocol mechanics. A holder acquiring ZCHF on Kraken bears both the risk of ZCHF deviating from CHF parity and the separate risk of CHF depreciating against EUR. These are compounding exposures that are distinct from any risk addressed by the protocol's collateralisation framework.

Supply elasticity and external price impact

ZCHF has no fixed supply. Minting and repayment activity within the Frankencoin Protocol occurs continuously and independently of trading activity on the admitted platform. Large-scale minting or position repayment events in the protocol may affect circulating supply while a holder is actively trading on Kraken, creating price movements on the exchange that originate outside the exchange's order book and are not visible within it.

Venue dependency and delisting risk

Access to ZCHF through the admitted trading platform depends on continued listing by Payward Global Solutions Limited (Kraken). Kraken may suspend trading, impose additional eligibility requirements, restrict access by jurisdiction, or delist ZCHF in accordance with its own policies without requiring consent from the offeror or holders.

KYC, AML, and access restriction risk

Trading ZCHF on Kraken requires account creation, identity verification, and compliance with the platform's eligibility criteria. Users who fail verification, reside in restricted jurisdictions, or are identified as sanctioned persons will be unable to access the admitted trading venue.

Regulatory and multi-jurisdiction risk

The regulatory treatment of decentralised, overcollateralised crypto-assets such as ZCHF under MiCA continues to develop through supervisory guidance and practice. MiCA is an issuer-centric regime and the definition of e-money tokens, asset-referenced tokens and other crypto-assets is relatively clearer for assets with identifiable issuers, but the recital 22 exemption, and the issuer-centric definition of electronic money, among other gray areas in legal interpretation mean that the consensus classification of ZCHF under MiCA may evolve over time, although in principle the matter should be superfluous due to the recital 22 exclusion from Titles II, III and IV of MiCA. In any event, legal evolution — through interpretation or levels 1 to 3 regulation — across EU member states or third-country jurisdictions may affect the conditions under which ZCHF can be admitted to trading, held, or used.

Market abuse risk

Crypto-asset markets may be susceptible to front-running, wash trading, spoofing, and other manipulative practices. These risks may be amplified at the time of initial listing or during periods of low liquidity. Market conditions on unregulated decentralised venues may influence prices on the admitted platform.

Not applicable as we could not identify an issuer for ZCHF.

Collateral value and over-collateralisation risk

ZCHF value stability depends on each outstanding position being backed by collateral with a market value exceeding the corresponding ZCHF obligation. A rapid or severe decline in the value of accepted collateral assets — particularly where multiple positions use correlated collateral — could result in under-collateralisation before the auction mechanism completes, resulting in losses absorbed by the equity reserve and a potential reduction in the ZCHF/CHF parity.

Auction duration and liquidation speed

The system's oracle-free design resolves liquidations through auctions that unfold over a period of hours to days, rather than the near-instantaneous liquidations possible in oracle-based systems. In periods of rapid collateral price decline, the auction mechanism may not resolve quickly enough to prevent under-collateralisation, particularly if multiple positions require simultaneous liquidation.

Collateral eligibility and concentration risk

Any collateral asset may in principle be proposed and accepted through governance. If the system accumulates material exposure to a single collateral asset or a narrow set of correlated assets, adverse price movements in those assets could affect system solvency disproportionately. The adequacy of the collateral pool depends on governance participants correctly assessing collateral risk at the time of approval.

Peg deviation risk

There is no hard peg mechanism. Value stability is maintained through economic incentives: over-collateralisation, the arbitrage opportunity created by peg deviations, and the ability of FPS holders to adjust minting costs. Short-term deviations from CHF parity are expected and constitute part of the system's design. Sustained or severe deviations may occur if market conditions, collateral stress or governance failures undermine the incentive structure.

Transaction irreversibility and private key risk

Transactions on Ethereum are irreversible once confirmed. Loss, theft or compromise of a user's private key results in permanent loss of access to ZCHF, with no mechanism for administrative recovery. Holders are solely responsible for secure key management.

Market liquidity risk

ZCHF may not always be tradeable at prices close to CHF parity if secondary market liquidity is insufficient. Liquidity on decentralised exchanges depends on the depth of liquidity pools, which may be reduced during periods of market stress. Thin markets may also result in significant price impact for larger transactions.

Savings module yield and equity pool dependency

The interest paid to ZCHF holders through the Savings module is funded from the system's equity pool, not from an external source or a fixed reserve. The applicable savings rate is set by FPS holder governance and may be adjusted or reduced to zero at any time following the standard seven-day veto window. Additionally, the equity pool from which savings interest is drawn is the same pool that absorbs losses from collateral liquidations. If the equity pool is significantly reduced by liquidation losses, the system's ability to sustain the savings rate may be impaired. Deposited ZCHF in the savings module is fully segregated and cannot be accessed to cover system losses, but the yield on that ZCHF depends on the continued solvency and income of the equity pool.

Governance proposal and veto failure risk

The governance system relies on FPS holders reviewing and where necessary vetoing proposed new minting modules. If a harmful or exploitable minting contract is proposed and passes without being vetoed — whether through insufficient attention, collusive or apathetic governance, or a failure to identify risks in complex code — it would gain the ability to mint and burn ZCHF without restriction within the system. The 1,000 ZCHF proposal fee reduces but does not eliminate this risk.

Extension module risk

The modular architecture permits new minting contracts to be added over time. Each new module introduces additional smart contract surface area and potential economic interactions with existing modules. The v2024 audit identified that the new liquidation mechanism introduced in that release could interfere with the existing one. Future extensions may similarly introduce unforeseen interactions.

Immutability and upgrade risk

All core contracts are immutable. This eliminates the risk of malicious or accidental upgrades to the token contract but also means that identified deficiencies in core contract logic cannot be corrected after deployment. New functionality must be introduced through separately deployed minting modules and governance approval, which may limit the speed and scope of remediation in the event of a material protocol issue.

Ecosystem and interface dependency

User interactions with the system depend on the availability and accuracy of the official application at https://app.frankencoin.com, supporting wallet infrastructure, RPC node availability and third-party services such as on-ramps and exchanges. Outages, inaccurate data, or interface changes may impair practical access to the system even where the underlying contracts continue to operate correctly.

Adoption and community risk

The long-term solvency and utility of the system depend on continued participation by collateral depositors, FPS holders and ZCHF users. Reduced adoption could reduce equity reserves, weaken governance engagement and reduce secondary market liquidity, each of which independently increases system risk.

Smart contract defects

The Frankencoin system consists of immutable Solidity contracts. Undiscovered defects in core contract logic — including the ZCHF token, the MintingHub, the Equity contract or any approved minting module — could result in loss of funds, incorrect accounting or system manipulation. Multiple audits have been conducted, but no audit process guarantees the absence of all vulnerabilities.

Oracle-free design limitations

The system's auction-based price discovery mechanism requires that potential challengers own or can acquire sufficient quantities of a given collateral asset to initiate a challenge. If a minter acquires a dominant share of a collateral asset's circulating supply, they may be able to prevent effective challenges, allowing unsound positions to persist. This is a known design constraint relevant to the collateral eligibility assessment process.

Cross-chain bridge risk

The CCIP bridge enabling ZCHF transfers between Ethereum mainnet and supported chains introduces additional technical risk. The ChainSecurity audit identified caveats regarding out-of-order execution and partial data transfer in cross-chain message handling. A bridge failure, including a failure of the underlying CCIP infrastructure operated by Chainlink, could result in loss of funds or state synchronisation failures. The ChainSecurity audit further noted the absence of a recovery mechanism in the event of bridge failure.

Ethereum Layer 1 dependency

The Frankencoin system's primary settlement layer is Ethereum. System operation is subject to all risks associated with Ethereum mainnet, including Ethereum client defects, consensus failures, network congestion, high gas prices, and risks associated with Ethereum's proof-of-stake validator set. Severe Ethereum network events could delay or impair transaction processing, position management and liquidation activities.

FPS vote accumulation and governance attack

The vote accumulation mechanism weights votes by FPS holdings multiplied by holding duration, rendering flash-loan-based governance attacks ineffective. However, a patient actor accumulating a sufficient FPS position over time could acquire veto power to block legitimate proposals indefinitely. The kamikaze function built into the FPS contract allows an altruistic participant to sacrifice their own votes to cancel an equivalent number of votes held by a target address, providing a defence mechanism but not a complete guarantee.

Quantum computing risk

The Frankencoin Protocol, as an ERC-20 system on Ethereum, relies on secp256k1 elliptic curve cryptography for address ownership and transaction authorisation. A sufficiently capable quantum computer running Shor’s algorithm could potentially derive private keys from exposed public keys, allowing attackers to compromise Ethereum addresses holding ZCHF, FPS, or protocol positions. Because the core Frankencoin contracts are immutable and non-upgradeable, any migration to post-quantum cryptography would depend entirely on Ethereum’s own protocol-level response rather than contract-level upgrades by Frankencoin itself.

Offer-related risks

• Venue dependency and delisting risk: ZCHF is not dependent on any single trading venue. Holders may transact on decentralised exchanges permissionlessly regardless of any centralised listing status. The protocol's open-source contracts and multi-chain deployment across eight networks ensure continued accessibility even if access through a specific regulated platform is restricted or suspended.
• Market abuse risk: Payward Global Solutions Limited (Kraken) operates as a regulated crypto-asset service provider subject to MiCA's market abuse provisions, including obligations to detect, prevent, and report manipulative conduct. The availability of ZCHF across multiple venues, including decentralised exchanges that publish all transaction data publicly on-chain, provides a transparent pricing benchmark that makes manipulation on any single venue readily identifiable by market participants.

Crypto-asset-related risks

• Collateral value and over-collateralisation risk: Every ZCHF in circulation must be backed by collateral with a market value of at least one ZCHF. Positions additionally require a minter reserve withheld at issuance, providing a position-level buffer before the equity reserve is affected. If a liquidation produces insufficient proceeds to cover the outstanding obligation, losses cascade through three layers: the position's minter reserve, the equity capital held by FPS holders, and the general borrower reserve. The total collateral backing the system is publicly verifiable at any time at https://app.frankencoin.com/monitoring/collateral. (docs.frankencoin.com/reserve)
• Auction duration and liquidation speed: The 2% challenger reward payable in ZCHF incentivises third parties to monitor positions and initiate challenges promptly when collateral values approach liquidation thresholds. The monitoring page at https://app.frankencoin.com/monitoring provides a real-time list of all open positions and their status, lowering the information cost for prospective challengers.
• Collateral eligibility and concentration risk: Any proposed collateral type must pass the governance veto process before positions may be opened against it. FPS holders with 2% or more of accumulated votes may veto collateral proposals they consider unsuitable. This process is intended to prevent acceptance of illiquid or highly concentrated collateral assets. The oracle-free auction mechanism also requires that challengers own or can source adequate quantities of the collateral, creating a structural incentive to reject proposals where challenger availability would be insufficient.
• Peg deviation risk: Every short-term deviation from CHF parity creates an arbitrage opportunity: ZCHF trading below parity can be purchased cheaply and used to repay positions, releasing collateral worth more than the repayment cost; ZCHF trading above parity incentivises new minting. This two-sided arbitrage mechanism is designed to push the exchange rate back toward parity without requiring any centralised intervention. FPS holders may additionally adjust the cost of minting through governance, providing a long-run calibration tool analogous to central bank interest rate policy. (docs.frankencoin.com)
• Market liquidity risk: ZCHF is available across regulated Swiss on-ramps (Mt Pelerin, DFX), decentralised exchanges (Curve, Uniswap, CowSwap) and centralised venues (MEXC), providing multiple access points for buyers and sellers. Deployment across eight chains increases the total pool of accessible liquidity.
• Savings module yield and equity pool dependency: The savings rate is governed independently of the borrow rate and is subject to the seven-day veto window, giving FPS holders time to reduce the rate if equity pool conditions deteriorate. The complete segregation of deposited ZCHF, which cannot be seized to cover losses, ensures that holders' principal is protected from system losses even if the yield is reduced or suspended.

Project implementation-related risks

• Governance proposal and veto failure risk: The 1,000 ZCHF proposal fee raises the cost of submitting harmful proposals. The community discussion forum at https://github.com/Frankencoin-ZCHF/FrankenCoin/discussions and the Telegram channel provide pre-proposal communication channels through which broad consensus is expected to form before a proposal is submitted, further reducing the likelihood that harmful proposals proceed unvetoed.
• Extension module risk: Each new minting module must be approved through the governance veto process and is expected to undergo security review before deployment. The ChainSecurity v2024 audit of the PositionRoller and Savings extensions confirmed that the system still relies on the same trust model as the original contracts, with no additional trusted roles introduced.
• Ecosystem and interface dependency: The Frankencoin protocol's smart contracts operate independently of any frontend. The complete source code is publicly available on GitHub, enabling community-built or third-party frontends and integrations should the official application become unavailable.

Technology-related risks

• Smart contract defects: The Frankencoin smart contracts have been reviewed by BlockBite (February 2023), a Code4rena competitive audit pool (April 2023, $60,500 USDC bounty), and ChainSecurity across three separate engagements covering the core contracts (October 2023), the v2024 extensions and the CCIP bridge. All high-severity findings identified across these audits were resolved prior to deployment. The codebase is open-source and publicly auditable.
• Oracle-free design limitations: The challenge mechanism design creates a natural disincentive against accepting collateral assets with limited circulating supply. Challengers require sufficient quantities of the collateral to sustain repeated challenges; accepting a collateral with too limited availability would leave positions immune to challenge, and this risk is expected to be assessed by FPS holders during the governance veto process.
• Cross-chain bridge risk: The CCIP bridge was independently audited by ChainSecurity, which confirmed a good level of security after remediation of a wrong assertion that could have led to data loss. The governance vote synchronisation mechanism is anchored exclusively on Ethereum mainnet, preserving governance integrity regardless of conditions on other chains. Additionally, the CCIPAdmin module provides a protocol-level emergency cut-off capability for cross-chain flows, enabling governance participants to halt bridge activity in the event of a detected exploit before it propagates to mainnet.
• Ethereum Layer 1 dependency: No protocol-level mitigation exists beyond the security properties inherent to Ethereum's proof-of-stake design, including validator slashing economics and the economic cost of reverting finalised blocks.

MiCA Crypto Alliance Opco Limited

984500CEB5773O38LE40

ZCHF

ZCHF does not operate as an independent consensus mechanism. As an ERC-20 token on Ethereum, it inherits Ethereum's proof-of-stake consensus for all transaction ordering and finality on mainnet.

Ethereum validators stake ETH and are assigned block proposal and attestation duties. Ethereum time is organised into 12-second slots and 32-slot epochs. One validator is randomly selected as block proposer per slot; committees of validators attest to the validity of the proposed block. Finality is established once two consecutive checkpoint epochs each receive attestations from at least two-thirds of total staked ETH. Reverting a finalised block would require the slashing of the relevant validator stakes, making such reversion economically prohibitive. On networks other than Ethereum mainnet where ZCHF is deployed, the applicable consensus mechanism of that network governs transaction ordering and finality. (ethereum.org/en/developers/docs/consensus-mechanisms/pos/)

The Frankencoin governance process operates above the consensus layer through the veto mechanism described in E.3, and does not itself constitute a consensus mechanism.

See H.5

2026-01-01

2026-04-29

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at : www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Land use: 144.74726 m²

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). Estimates on individual node weight, hazardous components and depreciation rate are used.
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). Usage of natural resources is approximated through land use metrics. Land use, water use and water recycling are calculated based on energy mix-specific estimates of purchased electricity land intensity, purchased electricity water intensity, and water recycling rates. Full methodology available at: www.micacryptoalliance.com/methodologies