Governance Processes

The Chainflip protocol can not be totally immutable. As with all existing blockchain networks, a governance process must exist in order to upgrade the network to support new blockchains, new pools, update fees, add new protocol features like lending and adjust rewards as needed.

Further, governance processes can be implemented which could significantly reduce the potential impact of unexpected events such as supermajority attacks, ransom attacks, and software exploits.

However, in order to preserve the decentralised nature of the protocol, the following principles must be observed:

1. Most importantly, effective control over user funds should never be given to any single party. Effective control means the ability to unilaterally control the flow of funds, or to permanently block access to funds. No single participant should ever be able to be described as a custodian of user funds.
2. Implicit and explicit approval of a majority of independent stakeholders is required to make changes to the nature of the protocol.
3. An honest Validator network should be able to expel and replace any nominated governance body.

Many blockchain networks function using upgrade processes, which require the consensus of the network participants to be processed. A common feature of these systems is through that of software upgrades. One or more development teams propose new versions of the software which alter the rules of the protocol and function of the network. Only with a majority consensus can these upgrades be successfully processed, and failure to achieve such a consensus prevents such changes from taking place.

Other protocols feature a nominated body to carry out upgrades on behalf of the protocol. The selection process and functions of these system vary greatly across the blockchain world.

Chainflip features a combination of both, where internal mechanisms allow for changes in the runtime via internal governance mechanisms, but other parts of the validator software also require explicit action on part of the validator network to enact breaking changes to the system.

The Governance Keys

The Governance Keys are arbitrary keysets that are regulated by the Validator network. The keys themselves can be any multisignature scheme that is compatible with the governance pallet that Chainflip Validators run. What this means is that the Governance Keys could be managed by any Threshold Signature Scheme, standard n of m scheme, or even a single key (though this would likely never be voted for). Who is behind said keys is a social matter dictated by weighted voting - DAOs, councils, companies or even single individuals could be elected as a governance keyholder with enough backing, though we will refer to them generally as “Councils.” A supermajority of stakeholders can at any time propose to elect a new Council.

There are two Governance Keys in the Chainflip protocol, each held by different Councils and used for different purposes.

1. The Governance Key: This key holds many responsibilities, and is intended to be held by the primary developers of the protocol, or a body that represents them. Outside of managing the upgrades process, the ‘Governance Council’ can activate essential governance processes which aim to protect the protocol from attacks, and software exploits. Members of the Chainflip Labs Security Council currently make up the 6 members of the current 3-of-6 Governance Key.
2. The Community Key: This key acts as a check-and-balance for the Governance key. Intended to be held by a body of community members separate to the primary developers of the protocol, this key has no special abilities by itself, but it is required to allow the Governance Key to use the more powerful security and governance features of the protocol. 9 all independent, non Labs members, are currently on the Chainflip Community Council, and 5 are required to sign.

The reason the role of check-and-balance of governance isn’t simply left to the Validators by default is because there may be scenarios where they aren’t the best arbiters of broader stakeholder interests. This is especially true in the unlikely cases where some or all Validator keys have been compromised by hostile attackers.

Further to this, Validators make up the heart of the protocol, but may not share the same views as swappers, integrators, brokers, liquidity providers, and developers that are also essential to Chainflip’s long term success. By having Validators implicitly and explicitly nominate a distinct and smaller governing body, the network can enact governance votes faster and with fewer conflicts of interest.

The keys are automatically deployed to Smart Contract Vaults and the State Chain Gateway contract by the Validator network, though a cooldown period is enforced to mitigate against attacks involving software exploits.

Voting in New Keys

The Governance Council and the Community Council can be rotated only through a token-weighted vote on the state chain. Anyone with a token balance on the State chain can vote in proposals, even those currently staked into Validators. The minimum threshold for a successful proposal is a 2/3rd+1 super majority.

Anyone can create a new governance process to vote on the replacement of either one of the keys on the State Chain at any time. Voters must opt in to any key rotation proposal in order for a vote to be counted. The proposals last for 7 days, and the token balances are only counted at the end of the proposal timeframe. Anyone that is actively unstaking or undergoing claims at the end of the vote will not have their tokens counted towards the result.

In order to provide the wider non-validator Chainflip ecosystem time to assess and interpret any potential governance handover, a cooldown period is required. By enforcing State Chain rules which prevent the rotation of both governance keys for a 14 day period, new keyholders will have to wait a week before the new keys are installed and usable.

Liquidity providers should therefore receive as much as 2 weeks warning that the protocol governance is being changed over to a new party as voted in by the Validators that may or may not be connected to the existing users and developers of the protocol. From there, they can decide if they wish to keep their assets in the system, or withdraw before any actions can be conducted by the new keyholders. Similarly, validators may wish to unstake during this cooldown window if they decide they do not support the holders of the new governance keys.

Thus, any party can become a Governance keyholder, but it requires not only support from a supermajority of Validators and other token holders but also implicit backing from the liquidity providers in place.

Runtime Upgrades & Hard Forks

The Runtime Upgrade process, which is enabled by the Substrate blockchain framework developed by the Polkadot ecosystem and used as the basis for the blockchain system that Chainflip is built on, changes the default nature of protocol upgrades from the traditional forking system, one which relies on manual binary upgrades, into one whereby the Governance Council has the ability to upload changes to the blockchain code directly to each individual node, and at a specified block height, have the responding nodes switch over to the new protocol rules seamlessly. This is a great feature to enable fast and lower-friction development, but doesn’t work perfectly in Chainflip.

Due to the Chainflip Engine, a sidecar binary that runs outside the State Chain runtime, Chainflip Validators aren’t always be able to be seamlessly upgraded in this way. If any changes in a runtime upgrade also require a change in the Chainflip Engine, Validators that have not updated this secondary binary may be suspended by the other Validators when they can’t meet the newly required functionality specified in the runtime upgrade. If a supermajority fails or chooses not to upgrade, the change is not processed.

Traditional forks are also still possible using the Grandpa finality module that ships with Substrate, although to date, the governance processes designed for the protocol will be a more appropriate method for both upgrades and for making major project direction changes amongst competing groups of participants by voting on new governance keys.

Security Considerations & Features

Decentralisation presents a challenging array of security considerations that centralised exchanges simply don’t have to deal with. Previous attempts at creating secure cross-chain systems have proven to be challenging in the wider ecosystem, with losses from security incidents in the cross-chain sector easily reaching into the hundreds of millions of dollars.

Here, we’ll explore some of the security properties of the Chainflip protocol, the range of security risks we have identified, the assumptions that we’ve made, and the features designed to mitigate those risks.

Potential Protocol Risks

No security profile can be built without a firm understanding of the risks to which the protocol is exposed. The surface area for faults and exploits with bad outcomes for protocol participants is not infinite, but it is larger than most blockchain projects. To begin, let’s enumerate some of the ways in which things could go wrong:

1. Liquidity could be lost or stolen through the AMM/State Chain logic - Liquidity Providers and swappers could experience potentially serious or even complete losses if the AMM logic or other related accounting systems within the blockchain fail or are exploited. By undermining the intended logic of the Accounting Layer, Validators could distribute funds incorrectly, leading to incorrect payouts. Attackers, if such exploits are discovered, could use them to drain funds into their own wallets.
2. Liquidity could be lost or stolen through the vault management system - LPs and swappers who have deposited funds and are waiting to be paid out could experience potentially serious or even complete losses if the Chainflip engine is compromised or exploited in this way. Close attention needs to be paid to the logic that regulates TSS ceremonies, broadcasting logic, and key rotation processes in the vault management system.
3. Validator private keys could be compromised, seriously undermining the security of the system as a whole if enough keys are compromised. Superminority and supermajority attacks could occur if this happens at a large enough scale. Individual Validators could also have all of their $FLIP stolen if their Validator key is compromised.
4. Validator private keys could be simply lost, which could result in the liquidity held by Validators being unable to be moved, potentially forever, if enough keys can not be recovered.
5. The $FLIP token market could collapse if the code which handles emission, rewards, and claims is compromised or exploited.
6. External chains could be attacked or experience major reorgs which would likely break the Chainflip Accounting Layer if incoming transactions that have been witnessed are later rolled back on the external chain.

Protocol Level Security Features

Many of the above risk areas can largely be addressed by enforcing good engineering processes, a comprehensive integration and unit testing suite, comprehensive internal and external audits, and offering significant bounties to penetration testers. After successfully operating for years with no major security incidents and billions in processed transaction volume, we are confident in the security of the codebase and our engineering processes that produces the code.

However, any complex software system that assumes that everything will work as intended, even if all the correct precautions have been taken, has failed to develop a comprehensive security plan. Redundancy is a key security principle and especially when applied in complex distributed systems with many moving parts like the Chainflip protocol. Our unique security features are designed to offer redundancy during many potential security incidents.

State Chain Safe Mode

As all of the above risks will impact the State Chain, and in fact most of the risks could arise from State Chain code, a system to pause some or all critical chain activity is essential in the case of a security incident.

Safe Mode is a chain state where Validators, by instigation of the Governance key, temporarily agree to halt some or most core functions of the protocol. In Amber mode, specific functions can be disabled, and in full Red mode, blocks continue to be produced, so that key governance extrinsics and events can be processed, but other functionality is heavily reduced. In full red Safe Mode:

• Witness extrinsics from the block at which the Safe Mode was activated are not accepted. Any ingress events that are not finalised will have to wait until after Safe Mode is deactivated to be rescanned and processed.
• Auctions and vault rotations are no longer automatically triggered.
• No Egress transactions are processed (No swap payouts, no LP withdrawals, and no new staking claims will be processed).
• Supply sync transactions are suspended.

Activating Safe Mode gives Validators, developers, and the community time to analyse security incidents in a reduced risk state. During Safe Mode, runtime upgrades and other fixes can be deployed to the network, allowing for a measured recovery process.

Once the incident is resolved, the network can exit Safe Mode by a governance extrinsic.

State Chain Gateway Protection

The State Chain Gateway is an Ethereum smart contract that allows holders of $FLIP an ERC20 token, to put up collateral on the Chainflip State Chain. This collateral is credited on the State Chain as an account balance which can be used to run Validators, Brokers, or perform active liquidity management activities. The State Chain Gateway contract also processes redemptions to send unlocked ERC20 tokens back to account holders after receiving a valid redemption certificate (a TSS 100 of 150 signature from the current Authority Set). The State Chain Gateway can call the $FLIP Token contract to update the token supply based on built in protocol emission and burning rules.

There are quite a few different ways this could be exploited. Namely, risks 1, 2, 3 and 5 are all relevant and could all cause losses if the State Chain Gateway contract is involved. To provide a layer of protection against risks 1, 2, 3, and 5, the State Chain Gateway comes with a feature which adds a 2 day delay before a user can actually claim tokens (executing a claim) from the contract after submitting a withdrawal certificate (registering a claim) to the smart contract. The delay itself changes little, but in combination with its second feature, it can play a major role in providing redundancy against attacks and losses related to bridging $FLIP.

The second feature allows the Governance key to suspend the State Chain Gateway from executing redemptions, or register new ones. If an issue where fraudulent or incorrect registered redemptions are detected within the delay window, negative impacts from $FLIP bridging-related incidents can be negated.

That being said, freezing claims indefinitely is not a solution. Any registered false redemptions would be able to be executed when the State Chain Gateway is unfrozen again if claims did not expire after some period of time. As the State Chain Gateway enforces an expiry time, which is set at the time of registering the redemption, the executions can not be processed by the State Chain Gateway contract after 3 times the length of the claim delay. In other words, on mainnet all unexecuted redemptions expire after 144 hours.

This means that in a security incident where the State Chain Gateway is frozen, a graceful recovery is possible if underlying issues on the State Chain can be resolved and the State Chain Gateway is unfrozen after all registered claims have expired, which should be within 144 hours.

During this time, the State Chain and Vaults could continue operating, unless they too have been affected by the incident, in which case Safe Mode is likely to also be active.

NOTE: The current iteration of the State Chain Gateway contract features a governance withdrawal function in tandem with the community key. It is unclear if this is necessary or desirable going forward, and its removal is slated for discussion.

Contract Vault Protection

Risks 1, 2, 3, 4, and 6 apply to the Vaults, and the losses that could be experienced due to these risks would impact liquidity providers and other users with collateral in the protocol, who could lose all of their funds, as well as swappers who are waiting for a payout.

Smart Contract Vaults also come with similar capabilities as the State Chain Gateway, however unlike the Gateway, there is no delay on payouts from the Vaults. This is necessary to ensure fast swapping times for users, but it does make the protections weaker than in the State Chain Gateway contract.

All smart contract based Vaults can be frozen out of band by the Governance Council. Upon witnessing this function being called, the Validators will no longer be able to process egress transactions from that Contract Vault. It is assumed that Safe Mode may already be active at this time in most scenarios, so this could already be the case, but does add an additional layer of protection for the large pools of liquid funds held in these vaults.

While frozen, the Community Council plays a significant role. If it is assessed that the contract or the network could be irreversibly compromised, or that the aggregate key has been lost or corrupted for good, a final option exists to ensure that funds remaining in the Contract Vaults can be recovered and returned to users and liquidity providers.

Within the Contract Vaults, the Community Council can call a function that authorises the Governance Council to withdraw all funds in the vault. This check and balance ensures that the Governance key never has unilateral control of the funds and must first both freeze the vault contract and then achieve approval from the community key before this extreme recovery method can be used.

Assessing Network Security Provided by the Validators

Chainflip is decentralised, but is not completely trustless. It is a trust-minimized protocol that does make a core trust assumption regarding the integrity of the Validator network. This is not unlike other successful protocols, such as that of Hyperliquid, Arbitrum, Celestia, NEAR, and many other rollups and protocols, which require that the user trust that a sufficiently large portion of the network is honest.

Chainflip offers a unique design for the creation of liquidity pools across multiple blockchains. The only way to make this possible without making changes to the supported blockchains is to have a jointly controlled wallet or smart contract on each of the supported chains, operated by the permissionless Chainflip validator network. Using threshold signature schemes, Chainflip can support wallets on each of these chains with as many as 150 signatories, with a 2/3rd majority being required to produce a valid signature from any given vault.

Validators in Chainflip are not only responsible for producing blocks, verifying transactions on the state chain, and regulating the supply of the FLIP token, but also have collective control over liquidity stored in the protocol’s vaults.

The Chainflip protocol guarantees that as long as an honest superminority (a blocking vote of 50 nodes) exists in the Authority Set, and the protocol has not malfunctioned, all witnessing, State Chain execution, and egress transactions on other chains will be executed deterministically, with no scope for falsification.

But, like any Proof of Stake/Proof of Authority system, it will always be possible that if a malicious actor takes control of an effective majority, that actor will be able to control many if not all of the core functions of the protocol.

This is a fundamental quality (and feature) of decentralised networks - it is always possible that with enough control, Ethereum, Bitcoin, Solana and every other credibly decentralised blockchain network are vulnerable to a majority attack. However, because of the way they are designed, and the value of these networks being derived primarily through social contracts, majority attacks are not usually a viable profit-making activity, and even for purely malicious actors, are too expensive and difficult to conduct in comparison to software exploit-based attacks. The truth remains, though, that it is always technically feasible, given a set of preconditions, to attack decentralised networks through majority attack and fundamentally undermine the security of the system.

In designing DeFi protocols, this is not usually a consideration - it is held as a given by the community that Ethereum and other blockchains are secure, even though it is always technically possible to undermine that assumption.

Chainflip differs from this assumption in one small but important way, but to explain this difference, it’s worth first exploring the security considerations of Proof of Stake in general for better context.

Chainflip’s Unique Security Profile

In Proof of Stake systems, such as that of the Ethereum and indeed Chainflip, it is much more difficult to make an apples-to-apples comparison in terms of the cost and therefore the profitability of an attack, due to the nebulous nature of the potential benefits and input costs associated with such attacks, which is why it is true that proof of stake Ethereum can be safely ‘undercollateralised’, even though it is difficult to quantify exactly to what extent at any given time.

However, Chainflip differs from PoS Ethereum in its security model for one main reason. On the Ethereum side, although billions are tied up in the state of the Ethereum blockchain and that state can be manipulated by attackers, as soon as the attack is spotted, the potential attack yields quickly dry up: the vast majority of off-chain markets that allow the selling of Ethereum assets into non-Ethereum assets will quickly pause deposits, freeze funds, and stop trades.

With Chainflip, the protocol controls funds that are not dependent on the security of Chainflip in order to retain their value. A Chainflip ‘hack’ would not trigger the universal freezing of related assets - in the worst case the attacker would gain access to liquid ETH, USDC, BTC other assets that will retain their value regardless of the performance of Chainflip, and would not necessarily have a limited window of time in which to sell off these assets. There also wouldn’t be a way to reverse this occurrence as Chainflip has no control over the governance processes of the chains it supports. Therefore, it can be said that the potential yield of a supermajority attack on Chainflip is probably greater than that of a typical Proof of Stake system.

The structuring of the cost of these attacks is however no different to that of a typical system - any attacking node will get their collateral frozen or slashed, or devalued to the extent that they may as well have been slashed. We can therefore express the theoretical purely economic profitability of majority attacks using two values: Exploitable Value (EV) and Cost to Majority Attack (CMA).

Hostile Takeover of Chainflip by Supermajority

For this analysis, we are assuming that no actor can realistically purchase a sufficient amount of the circulating supply of FLIP in order to gain a supermajority of Authority slots due to the wide distribution and diverse operator set already present in the network. Even if it were possible to buy one’s way into a supermajority, the community would notice a large block of unknown nodes taking over the network, and consequently respond either by outbidding them, or removing assets from the system to safeguard them.

There is a more likely attack that is also cheaper: coordinating the collusion of a sufficiently large block of validator operators. If we can economically secure the system against malicious collusion, we can also say it’s economically secure against a unilateral supermajority.

A colluding hostile supermajority must carefully execute their plan. For an attack to maximise its potential economic benefit to the attackers, it has to be prepared without the wider community noticing. If the attacker reveals any information about the attack prior to pulling the trigger, intentionally or otherwise, it can be assumed that at least some users will withdraw their funds from the system, reducing the overall EV, and also the value of collateral held by validators if it has an impact on the FLIP price, triggering losses for attackers before the attack is even conducted.

This raises some questions about whether a collusion attack is even possible in practical terms - the attacker would have to reveal themselves to validator operators, delegators, and potentially dozen of other actors, either by direct communication or a shift in the control of the delegated staking system which sees unknown actors taking a majority of Validator slots in the Auction system. If anyone acts honestly and reports the supermajority attempt, users of Chainflip are able to withdraw their funds at any time and take the potential windfall of an attack from the system if there is suspicion of a dishonest takeover. Other major honest actors in the system can also respond by outbidding apparent incoming malicious actors in the auction system.

In sophisticated collusion attempts, the attack could rapidly collapse and if sufficient evidence is gained, any complicit validator could be slashed through community action before the attack has even started. The threat of exposure alone is potentially enough of a deterrent to make Validator operators think twice before even considering this. Right away, we have hit a potentially fatal problem for actual supermajority attackers, but for the purposes of continuing this analysis, we’ll assume that collusion is possible if it’s profitable to do so.

Assuming the vast majority of validators are financially motivated and aren’t interested in losing money on this attack, we can say that so long as the Explotable Value (EV) remains below the Cost to Majority Attack (CMA), the system is secure against financially motivated supermajority attacks, including both attacks through collusion and unilateral supermajority attacks.

Assessing Exploitable Value (EV)

The first question to answer is: How much money can be taken during a supermajority attack? If the attacker really does have unilateral control over the supermajority needed, then they can take all of the non-native FLIP funds immediately - even in the Vault smart contracts.

All smart contract based Vaults can be frozen by the Governance Council. Wehn activated in the smart contract, the Validators will no longer be able to process egress transactions from that Contract Vault. It is assumed that Safe Mode may already be active at this time in most scenarios, so this could already be the case, but does add an additional layer of protection for the large pools of liquid funds held in these vaults. However, in a Supermajority scenario, these protections mean nothing. In a very short window of time, a colluding supermajority could move all funds to wallets or contracts in their direct control before any of the governance functions could be called to protect the funds held in these contract vaults.

However, FLIP held on the State Chain Gateway cannot be traded and requires a 2-day withdrawal process to move on Ethereum where it could be sold. The StateChain Gateway is also protected by governance protections on Ethereum and effectively means that attackers can not expect to steal the locked stakes of other validators or recover any value from their own stakes by supermajority attack.

The Exploitable Value of a super majority attack is therefore simply the value of liquidity collateral held in the system, and excludes the value of FLIP altogether.

Assessing CMA

With our first variable defined, EV, we now need to ascertain how to calculate the Cost to Majority Attack (CMA). As discussed in the previous section, it is assessed that the cheaper and most likely method of attack would be through collusion, and not through direct control of enough tokens to outbid enough validators to form a supermajority controlled unilaterally by one attacker.

A “Malicious Buyout” has been assessed in a number of other crypto-economic contexts. The long and the short of the story is that an attacker has better options at their disposal to attack the network, whether or not they are financially motivated. An attacker trying to conduct a “buyout” does in turn drive up the value of the token - whether or not this is over time it can still be said that a buyout strategy is extremely capital intensive, and with the other protections in place in this analysis, would certainly cause the CMA to increase non-linearly as the buyout is conducted. Even if the buyout is extremely gradual, the attacker is also exposed to the risk that the EV in the system drops over the course of the buyout for reasons external to the attacker, making this type of attack both extremely capital intensive compared to the potential benefit and also risky, with so much upfront cost and time required to conduct it efficiently.

Instead, we’ll look at the better attack method - operator collusion. If an attacker can convince a sufficiently large enough group of validator operators to install modified validator software and risk their existing stakes in the network in return for a share in the EV from the attack, this is much cheaper and less risky to the attacker than a majority buyout.

It’s worth pointing out that all stakes in Chainflip validators can be arbitrarily frozen in the Stake Manager contract within the 2 day withdrawal cooldown period. This means that the emergency key, while it can’t slash validators arbitrarily, can freeze the stakes of attackers indefinitely. Even in the most extreme scenarios, attacking validators can be completely blocked from accessing their collateral, and thus stand to lose all value stored in the FLIP collateral immediately upon attacking.

The real question is whether or not an attacker would be able to convince enough validators to pull the attack off. Assuming that most validators are purely financially motivated, the attacker would have to offer terms to the colluding parties that exceed the value of the stake that they’d be losing by participating in the attack. We can say definitively that if the value of FLIP collateral stored in 100 of 150 nodes is worth as much or more than the EV, then a financially motivated attack is nonsensical.

In this basic assessment, we could simply define CMA as the value of the FLIP required to run 100 Validators, but this fails to consider other essential factors. Agreeing to participate in a collusion attack is not without risk, and it is important to factor in the pricing of this risk to assess the security of the network against collusion attacks.

Pricing in the cost of Risk

An attacker must also consider how validators will price in risk when considering an attack. The risk is not zero - everything from getting slashed ahead of the attack to potential legal consequences are all considerations that validators would consider before deciding to join the colluding parties and the attacker.

It is very difficult to quantify the average operator’s risk tolerance and therefore the pricing of such risk, but it is quite clear that these risks alone would make it extremely difficult to convince a supermajority of validators to participate in a collusion attempt. The cost of even considering an attack is non-zero.

A collusion attack that steals LP and user funds would absolutely be considered criminal activity in almost any jurisdiction with affected victims, usually under computer hacking laws which carry serious penalties.

This raises a bigger point - one that many security analysts will be quick to dismiss as a consideration, but one we think it is worth pointing out: There will always be a proportion of the validators that are unwilling, under any circumstances, to participate in a collusion or supermajority attack. The realities of participating in a “hack” like this are such that we believe the vast majority of validators would never accept the risk of being associated with a theft event.

With the bulk of Chainflip’s validators having some sort of public profile or being traceable through blockchain history, and with that fact unlikely to change in any foreseeable future, the potential for reputational damage and legal consequences is enough to deter the majority of validators from ever considering a collusion attempt under any circumstances, irrespective of the potential bounty.

Delegators are also therefore heavily incentivised to choose Validator operators who are honest, public, and identifiable. If the operators act maliciously, delegators stand to lose all the value of the FLIP they have staked with them. It is for this reason that we enforce a minimum operator fee across the board for delegated staking, as no malicious actor can come in and convince FLIP stakers to stake to low or no-fee nodes in order to win control of the network. If everyone charges the same, profitable fee, then Delegators are more likely to choose honest, identifiable operators who they can come after should the operator become malicious.

Overall it can be said that there will always be a subset of the validators that will always act honestly no matter what. It’s not altruism or some moral issue - it is also economic in nature. Rational economic actors generally pay their taxes and avoid legal disputes because entering such situations is incredibly costly, both economically and on a personal level. The same considerations apply in this scenario.

However, we can also say that malicious actors will also have to factor in some risk premium to conducting an attack, which for the purposes of calculation, we will set at 50%.

The Real Threat

The real supermajority threat is something much simpler - someone with no skin in the game that finds an exploit in the validator software that allows them to hijack the network, which they can simply use to conduct a supermajority attack without any involvement or actions required by the validator operators. Hackers like this are the far more likely security threat, and no amount of protocol or crypto-economic design or analysis can overcome them. Instead, extensive security analysis must be conducted on the validator software to ensure it remains secure from the first day of operation.

Further, compromised keys will not be noticed by the operator until one day the attacker has quietly collected enough of them to launch an attack. Attackers like this could be anyone - they aren’t going to be capital rich firms and investors, and genuinely could see their quality of life improve after conducting an attack.

But there’s even lower hanging fruit than that. As we have seen over recent years, exploits in DeFi protocols have often allowed attackers to steal money from protocols without being involved in the network at all. Software exploits in DeFi regularly allow attackers to get protocols to bend to their will on a regular basis. There have been hundreds of millions taken from contracts, and THORChain, the only real comparable project the Chainflip’s design, has had an unfortunate months-long string of software faults and exploits that have led to losses and failures. Economic security is a distracting topic when the real threat to protocol security lies not significantly in the high-level design but in the architecture and implementation of the protocol software itself.

In any case, let’s summarise the absolute minimum expected cost of attack.

Summarising CMA

We can summarise the Cost to Majority Attack as:

CMA = AttackingValidatorStakeValue ) + (AttackingValidatorStakeValue * RiskPricingPercentage)

Estimating the “Security Ratio”

If EV is less than CMA, then a purely economic attack is not profitable and the system is secure against purely profit driven malicious majority attacks. Given that EV is largely derived from how much liquidity there is in the system, and CMA is derived from how much collateral secures it, we need to find out the maximum ratio between the two to figure out how much value Chainflip can secure using this design. We’ll call this ratio the Security Ratio. Given that:

EV = LiqudityInChainflip

And;

CMA = AttackingValidatorStakeValue + (AttackingValidatorStakeValue * RiskPricingPercentage)

The Security Ratio Safety limit can be derived by solving for EV = CMA using the values discussed in this analysis.

LiquidityInChainflip = 1.5 * AttackingValidatorStakeValue

Because the minimum value for attacking Validator Stake Value must be at least two-thirds of the validators to derive a 100 on 150 minimum signing group for any validator controlled threshold key, the value of AttackingValidatorStakeValue can be defined as 2/3rds of the TotalFLIPCollateralValue.

This gives us a helpful means to calculate the Ideal Security Ratio:

LiquidityInChainflip ≤ 1.5 *(TotalFLIPValidatorCollateral*0.66)

In other words: for every $1 of value staked across all active validators, we estimate that Chainflip can completely secure up to $1 of liquidity in the vaults against an entirely malicious Validator set.

However, on account of the very real risks posed to potential otherwise honest Validator Operators, we assess that this Ideal Security Ratio can be safely exceeded. Users storing funds in Chainflip as either LPs, borrowers, or other actors should be aware of these security dynamics and should regularly assess the makeup of the Validators of the system to ensure that at least a superminority of honest, identifiable, and public operators control the network. So long as the majority of Validators running the network can be identified, the practical risk of a supermajority attack are slim to none.

Delegators play a critical role in ensuring that the operators in control of the network have sufficient stake to retain this position. Delegators are incentivised to pick the right operators, else they risk the complete loss of funds in the event of a supermajority attack. The FLIP community should play an active role in identifying unknown or risky operators and ensure that sufficient FLIP is put in the hands of honest actors to prevent a loss of network control.

Conclusion

In this article, we have attempted to comprehensively analyse the economic security of the Chainflip protocol against financially motivated attackers. We have done so by analysing the primary and most profitable attack available to majority attackers: a collusion attack that steals all available funds from the liquidity vaults. We have estimated the value of mitigating measures that reduce the potential windfall and increase the potential costs of such attacks, and have defined a ratio of liquidity to collateral which can be used to assess if a purely malicious network would profit from such attacks.

Delegators should ensure that stake is granted to honest, identifiable operators that would face real world consequences were they to be implicated in any attack. Users should assess the honesty of the Validator network periodically and decide for themselves if they are comfortable with the risks given the current state of the network and the resulting Security Ratio, and remove their funds if they are concerned about risk of attack.

When it comes to security, attention should mostly be focused on typical code level security problems which continue to plague crypto products on a near daily basis. Chainflip is not immune against code exploits and other simpler issues which are far more likely to be the target of attacks as the protocol develops and evolves.

However, we also have plans for potential hardening measures should the market deem them necessary.

Future Economic Security Hardening Measures: Guarded Vaults

As Chainflip continues to be adopted, it may be the case that growth in the network value is seen to be insufficient to protect all these new assets from a potential theoretical supermajority attack, and as such, we present a potential path forward when and if such concerns arise.

This feature is considered optional and introduces problems of its own, but we post it here to demonstrate an understanding of the issue.

Background

Chainflip’s economic security model relies on the existing proof of stake system to secure the LP assets held in the vaults by validator supermajority (100 of 150).

For the purposes of securing enough liquidity to provide a functioning, high throughput cross-chain swap exchange, this model has to date been successful in discouraging economic attacks on the network.

It only takes an honest 1/3rd superminority to keep all funds in the protocol safe. So long as the users of the protocol generally perceive at least 1/3rd of Validator operators as honest actors, then LPs and lending users should be generally comfortable with economic security.

That said, introducing Lending into the protocol will mean a significant increase in funds held in the protocol. Generalised lending in particular has the chance to balloon the amount of assets held in the protocol.

Despite an expected increase in the network’s value due to the increased network revenue earned from these new features and the associated increase in swap volume on account of liquidations, there is likely a limit on the amount of growth that the network can experience due to perceived risks of a supermajority attack if the ratio of LP capital to Validator collateral grows too large.

One could argue that the network becomes inherently more valuable if the TVL grows, as game theoretically, the FLIP used to secure the network becomes more valuable to a potential attacker as the value held in the protocol also grows. However, this is only true if users do not care about the potential of such an attack, which is unlikely to be indefinitely true if it becomes unclear that the network is being controlled by honest actors.

As such, the protocol stakeholders should consider implementing a system which limits the potential upside of such an attack, and makes it economically unviable to do so. Guarded Vaults Similar to how centralised exchanges have a ‘hot’ and ‘cold’ storage system, where system funds are held in a mix of wallets with differing security properties, Chainflip could also implement a system which secures a percentage of the network’s funds in a secondary vault with different security properties.

A ‘Guarded’ vault is a secondary vault in which excess funds are stored by the protocol. Unlike the standard vaults, guarded vaults use one or more entities external to the network to perform the role of a known honest actor. Along with the standard 100 of 150 keygen and signing process, transactions from Guarded Vaults also require the signature of a Guardian (which could consist of one or more signers) in a secondary round to complete a signing ceremony successfully.

Transactions from a Guarded vault, according to the runtime rules, should only be between the Standard and Guarded vaults. Guardians can also never propose transactions - without the express request of the decentralised network, Guardians hold no power to transfer funds held in a Guarded vault.

In this way, Guardians do not add an element of centralisation to the core runtime of the protocol - all user interactions are processed in the Standard vaults, and unless a Guardian colludes with the rest of a corrupted network, can only ensure that transactions proposed to remove funds from these cold storage vaults are following the core runtime rules - something which a supermajority attacker would need to bypass completely in order to carry out an attack.

This is sufficient to disincentive an economic attack against the network, as the windfall of a supermajority attack is therefore limited to the funds held in standard vaults, which are in turn limited to a value equal to the economic security provided by the standard validator network.

When users require funds from the network, but the Standard vaults do not hold sufficient funds to fulfil this requirement, the network must first propose a vault transfer which shifts funds on-chain from the Guarded vault of that chain to the Standard vault, and then process a subsequent withdrawal as per usual. From a user perspective, this would occur completely in the background, at the worst causing a delay in withdrawal while the vault transfer is completed.

Guardians never take custody of user funds, and have no ability to transfer funds without the express authority of the rest of the Validator network.

Operationally, a Guardian could be a custodian, designated validator operator, protocol developer, foundation, or any other entity or combination thereof. From a technical perspective, a Guardian would run the same software as any other Validator, but be designated a special role. The Guardians selected should be based on the generally accepted premise that they are honest and identifiable actors. So long as they are publicly known, a Guardian has every incentive to not participate in an economic attack, as they will be easily culpable in any subsequent investigation into such an attack and theft.

Guardian Risks

Guardians present a new risk to the network in that they act as a point of failure during rotations and transaction processing of Guarded vault transfers. With a single guardian, downtime would mean a pause in rotations and transfers out of cold storage until they come back online again. It would therefore be a good idea to have more than one, and Guardian selection should also consider the competence of the operator to keep and maintain access to the keyshares and keys associated with the Guardian account, as well as remain online.

If the Guardians are compromised, they do not present immediate risk to the network. Guardian keys do not allow for transfers without the approval of the wider network, and thus a compromised Guardian only weakens the economic security protection, but not the integrity of the network. Furthermore, the possibility of a ransom by means of compromising the Guardians isn’t viable, so long as the honest actor has access to backups of the keys.

Guardian Governance

From a governance perspective, Guardians could be designated and selected in a similar fashion to how the protocol governance currently works, with authority of this role designated through time delayed token weighted governance voting.

It is likely that Guardians will need to be compensated for their services, either through emissions or for a share of protocol revenues.

This concept in principle solves the economic security issues which may deter further TVL growth, but further debate about exactly how Guardians are selected, rewarded, managed, and removed from the network is a matter that will require further deliberation between the protocol stakeholders.

This feature is currently not under development.