Security is a fundamentally hard and asymmetric problem for any software company. There is no magic bullet — in the last month alone there have been several notable compromises of technology companies (e.g. Okta, HubSpot). However, the self-custodial, irreversible nature of crypto means security compromises can result in the permanent loss of billions of dollars. This ongoing risk is a big challenge for NFT projects with long-term ambitions.
Hundreds of millions of dollars of user funds being lost massively damages the reputation of the space, and seriously harms the companies and projects involved. This risk is unacceptable to many businesses who are moving into the space, particularly those with existing customer bases, reputations and legal obligations. Security is therefore becoming increasingly important as a criterion for NFT projects selecting a platform.
Every platform has a strong incentive to position themselves as sufficiently secure. The truth is that all solutions have trade offs — the important thing is that projects have a very clear understanding of the specific trade offs they and their platform are making.
I’m Alex Connolly, CTO and co-founder of Immutable — we build one of the leading platforms for high-scale, high-quality NFT projects (and games in particular). I wanted to write this article to provide a detailed and mostly impartial assessment of the choices made by some of the most popular NFT platforms, including Ronin, Polygon, Immutable, Solana and Optimism. In particular, I will focus on two core elements of each platform’s underlying security:
- Consensus Security: the difficulty of stealing assets by attacking the platform’s nodes/validators (e.g. through a 51% attack)
- Bridge Security: the security of the mechanism for moving assets to and from Ethereum. This is usually the larger concern, as compromises generally put user funds directly at risk
This article will be a deep dive, with the technical detail necessary for project leaders to make informed choices. If you’re just looking for the TL;DR, try this table:
I promised details — let’s dive in.
Ronin
Ronin is a blockchain created by Sky Mavis Labs, which currently exclusively powers Axie Infinity and its ecosystem.
Consensus Security
Ronin is a “sidechain” — a blockchain with its own nodes and consensus mechanism, but one which maintains an official “bridge” to Ethereum. Ronin is a proof-of-authority (POA) chain, with 10 nodes, who stake their reputation on the fact that they won’t abuse their power. This is comparable to an Ethereum test net such as Goerli (20 node POA). If any 5 of these nodes (50%+) were to become malicious or compromised, they would be able to conduct a 51% attack on the network and steal user funds via double spends or other attacks. In general, this is considered to be an extremely low number of nodes (Bitcoin has 15000, and Ethereum has close to 6000), and produces a more centralized network in exchange for faster, cheaper transactions. Additionally, users cannot run their own nodes, and the source code for a Ronin node is not public and therefore cannot be audited by Ronin users.
Bridge Security
Ronin’s official Ethereum bridge is controlled by a 5-of-9 “multisig”. A multisig requires m signers out of a total of n key holders to approve each transaction. In Ronin, every bridging action requires approval from this multisig. However, there is no mechanism to check that the deposits or withdrawals were actually valid — anyone with access to 5 of the 9 keys can withdraw any amount of any token held in the Ronin bridge to any Ethereum address. This means any user of the bridge is directly trusting this multisig with all their funds.
In March 2022, this trust was exploited for $625 million after a hacker gained access to 4 keys held by the Axie team and 1 key which the Axie DAO Validator had lent to the Axie team (giving them 5/9). What we know so far suggests this was a classic cybersecurity exploit, which had serious consequences because of the centralization of these validator keys. Sky Mavis has committed to reimbursing those who lost funds, and reaching 21 independent validators over the next three months to ensure Ronin is more resilient to future attacks, though there may be a tradeoff between a more robust consensus/bridge mechanism and the scalability of the network.
Polygon
Polygon currently offers a proof-of-stake Ethereum sidechain (Polygon PoS), and a dedicated NFT services business, Polygon Studios, which supports major projects like Skyweaver and ZED RUN. Polygon is moving towards providing an array of different scaling solutions, most based on zk-rollup technology (discussed later), but currently only Polygon PoS is live as an NFT platform.
Consensus Security
Polygon PoS is a sidechain with a similar basic model to Ronin, except that Polygon is a “commit sidechain”, which periodically commits checkpoints of the chain’s state to Ethereum. There are two main components to Polygon PoS consensus. First, the Bor chain, which is where Polygon transactions actually happen: a rotating subset of block producers is chosen from a larger pool of validators to run a modified proof of authority network, which decides transaction inclusion and ordering. However, only 1 block producer of this subset (see PolygonScan block validators) is then chosen to propose 64 consecutive blocks (a sprint).
Next is the Heimdall checkpointing system, where a larger number of validators (currently capped at 100) come to ⅔ “proof of stake” consensus on a summary snapshot of the last ~30 minutes of Bor blocks, and publish that snapshot as a checkpoint on Ethereum. However, though there are 100 validators, 4 validators control 53% of the stake, and 7 validators control 67% of the stake (see here, click “show all” and sort by stake), and the ⅔ majority required refers to the stake, not the number of validators. This means that only 7 keys would have to be compromised for all funds on the chain, not just those on the bridge, to be stolen through malicious checkpoints — and stakers must keep their keys hot at all times. Additionally, as ⅔ of the stake is required for quorum, and 43% of the stake is controlled by 3 validators, compromising only 3 hot wallets would be enough to freeze withdrawals and checkpoints entirely.
A contract upgrade could be used to defend against malicious checkpointing (assuming it was detected quickly enough) — but that has its own security risks, as we’ll discuss next!
Bridge Security
Polygon’s bridge differs from Ronin’s in that the checkpointing system eliminates the need for an independent validator set to sign each deposit and withdrawal. However, this means the security of the bridge is fully reliant on Heimdall and Bor consensus, which is vulnerable to the attack described above.
Additionally, Polygon uses a 5-of-8 multisig to govern their bridge smart contracts, and contract updates can be made immediately, with no timelock. This defends against a smart contract bug or a compromise of the stakeweight validators as discussed above. 4 of the keys are held by the Polygon founders, a structure which has been strongly criticized by security researchers in the community, as with only one other key it would be possible to fully drain all funds from the Polygon contract ($5B+) through a malicious upgrade. However, as Polygon signers do not sign every deposit and withdrawal transaction, these admin keys are able to be kept offline, making them less likely to be compromised.
Immutable
Immutable is a platform for building high-quality, high-scale NFT projects like games. Notable projects building on Immutable include Illuvium, Gods Unchained, Ember Sword and Guild of Guardians.
Consensus Security
Immutable is a zk-rollup, built using StarkWare’s StarkEx prover/verifier system. This means Immutable orders a batch of L2 transactions, generates a STARK proof that those transactions are valid, and submits that proof to an L1 smart contract “verifier” which updates some L1 state (in our case, the root of a merkle tree containing millions of user NFTs/balances). Importantly, this scales substantially better than naively batching transactions, as STARK proof verification costs scale sub-linearly with the number of transactions.
As all state transitions must be verified by an L1 smart contract, Immutable can never insert invalid transactions into the rollup, or steal assets, even if Immutable’s systems were fully compromised. This is an extremely strong security property, and part of the reason Vitalik described rollups as “the key scalability solution for Ethereum for the foreseeable future”.
However, Immutable operates as a “single operator” rollup (only Immutable can order or prove transactions). This means Immutable could extract MEV by frontrunning or reordering transactions. Almost all rollups are currently “single operator”, though most have plans for decentralization over time.
Bridge Security
Rollups use a fundamentally different bridging structure to sidechains because they maintain a verified “state” on L1 which can only be updated with a valid proof. Bridging funds requires this verified state to already include your deposit/withdrawal — there’s no multisig to attack (e.g. Ronin), and no way to add “fake’’ state transitions by compromising validators (e.g. Polygon) — every transaction is verified as if it had happened on L1. This trustless bridging is why rollups are referred to as “L2s’’ — they rely directly on Ethereum’s consensus for their security, rather than a separate consensus mechanism with a trusted bridge.
At any time, users can submit a “withdrawal” transaction to bridge their funds from L2 to L1. If Immutable includes this transaction in the set of proven state changes, users are able to trustlessly withdraw their funds directly to Ethereum. If Immutable does not process this withdrawal (either unavailability or deliberate censorship), users are always able to use a “full withdrawal” flow by interacting directly with the L1 bridge contract.
If this new “full withdrawal” request is not serviced, the exchange state will be frozen and all users will be able to withdraw by providing the path to their assets in the state merkle tree. Ensuring users have access to this data, even if Immutable is malicious or offline, is the “rollup data availability problem”. In the standard zk-rollup construction, this has a simple solution: require the necessary data to be posted on Ethereum L1 before allowing state updates. However, this introduces a small linear gas cost which many applications are unwilling to pay. This cost will not change after the Merge, but will be substantially reduced by proposals like EIP-4488, proto-danksharding, and (eventually) sharding as Ethereum embraces its role as the base verification and data availability layer for rollups.
However, as none of these solutions are live, and the cost of posting calldata on-chain remains prohibitive for use cases like high-scale NFT minting, Immutable currently operates as a validium rollup. Validium rollups are zk-rollups which do not post all data necessary to reconstruct the state, in exchange for cheaper transactions. To ensure this data remains available even in the event that Immutable is offline or malicious, Immutable relies on a “Data Availability Committee”. A majority of this committee (made up of prominent ecosystem companies) and several “mandatory” members must sign each batch to prove they have the necessary data. This is different to a validator multisig: as long as any of the DAC are honest, users will be able to withdraw successfully. Even in the event of a data withholding attack where the entire DAC and sequencer were compromised, Immutable could still use a contract upgrade to prevent a ransom attack.
Immutable’s rollup verifier contract can be upgraded, but has a 14 day timelock, which would give users the opportunity to exit the system (even with Immutable maliciously censoring transactions) in the event they are uncomfortable with the new contract.
Immutable is in the process of moving to a Volition model, where individual “vaults” (user, token, quantity tuples) can be marked as requiring on-chain data. As the majority of value stored in the rollup exists as either large token/ETH balances or high-value NFTs, that value can be stored in a relatively small number of on-chain data vaults. This construction will likely allow the substantial majority of value in the rollup vaults to be backed by on-chain data, reducing the data availability risk while retaining the ability to do the cheap, high-scale NFT mints which are crucial for projects like games.
Solana
Solana operates as a fully independent L1 blockchain, with a deliberate focus on achieving low-cost, high-scale transactions through a custom consensus mechanism.
Consensus Security
Solana currently has more than 1500 active nodes, though it does impose substantial hardware requirements on those nodes to achieve its higher TPS (reducing the ability of individuals to validate transactions, an important tenet of blockchain decentralization). Importantly, a superminority of 20 nodes currently controls >33% of the staked SOL. If these nodes colluded, or were compromised, they would be able to halt the network or arbitrarily censor transactions.
Bridge Security
As a fully separate L1, Solana has no official bridge to Ethereum. However, the most popular (and semi-official) bridge for Solana users is Wormhole, which allows assets to be moved across a number of chains. Wormhole relies on a set of validators called guardians, which reach ⅔+1 proof of authority consensus on all bridging actions. There are currently 19 active guardians. As Solana and Ethereum cannot verify each other’s transactions, the bridge contracts depend entirely on the consensus of the guardians when bridging assets. This means that if ⅔ of these guardians were compromised, all user funds within Wormhole could be stolen. This mechanism is actually very similar to that used by Ronin, and unfortunately the guardian keys must also be kept hot to sign new transactions.
In early 2022, a bug in Wormhole’s bridge allowed $325 million of user funds to be stolen. This was actually not a compromise of the validator system, but the discovery of a smart contract bug which allowed the attacker to trick the bridge into issuing ETH on Solana that hadn’t been deposited on Ethereum. Jump Crypto stepped in to make users whole — an amazing indication of the deep pockets in crypto, but a wholly unsustainable model for the space as it grows. This isn’t an indictment on Solana or Wormhole — all on-chain systems are vulnerable to smart contract bugs. While there can never be guarantees, it is best to use audited/formally verified contracts which have stood the test of time and public scrutiny — Wormhole, for instance, was subject to intense scrutiny in the wake of the bug and no further bugs were found.
Optimism
Optimism is an Ethereum optimistic rollup developed by Optimism PBC. It hit mainnet in August 2021 for whitelisted projects, and has so far seen limited adoption from NFT projects, though there’s an early community on marketplaces like Quixotic.
Consensus Security
Optimistic rollups work similar to zk-rollups: gather transactions and upload a compressed version of the end state of all these state transitions. However, where zk-rollups provide a “validity proof” with each state transition, optimistic rollup transitions are assumed to be valid unless someone can produce a “fault proof” which shows an invalid transaction taking place. If someone can produce such a proof, they are rewarded and the publisher of the proof is punished. To allow for this challenge to take place, Optimistic rollups require a 1 week dispute time delay before transactions are completely final. This asynchronicity introduces an interesting class of potential economic attacks, and mitigating these is an active research topic.
However, Optimism’s fault proofs are currently disabled — meaning Optimism (or anyone who compromised the Optimism multisig) could steal all user funds by submitting invalid state transitions. This is a temporary state and will be upgraded once the new fault proof system is ready, but poses a serious danger to user funds in its current state. As Optimism is a single sequencer rollup, it is also open to potential MEV extraction.
Bridge Security
Optimistic rollups also provide a trustless bridge to Ethereum. However, because any user could challenge the validity of the batch at any point in the 1 week dispute period, assets which are withdrawn to L1 are locked for at least that period of time. For fungible assets, it is possible to circumvent this lockup using “fast withdrawals” (effectively lending to users on the assumption that the state transition contained no fraudulent transactions). However, as NFTs are unique and can’t be substituted, users must wait the full dispute period (up to a week) before they can move their assets back to L1 Ethereum.
Optimism (like all Optimistic rollups) requires intermediate transaction data to be posted on chain so it can be challenged effectively — this produces higher fees, but circumvents any complex data availability constructs as discussed in the analysis of Immutable.
Security Beyond Core Platforms
Having the best core platform security in the world is immaterial if your project’s security is compromised through another mechanism. To truly make informed decisions, NFT projects need to consider a variety of factors beyond consensus and bridge security, including:
- Wallet Security: how are user keys stored? What would be the impact if this storage system were compromised (e.g. a custodial wallet provider, a bad version of a native wallet app, a bad dependency in a browser extension)?
- Metadata Security: how is asset metadata (including images) stored? If this metadata was altered or replaced due to a compromise, what would be the market impact?
- Project Security: projects on any platform usually retain some admin keys for their project. What would happen if those keys were compromised? Does your project have active monitoring for breaches? Does your platform support best practices for key management?
- Treasury Security: most platforms will have substantial reserves of their token (e.g. for use in rewards or grants). How are these funds held? How are transfers from the treasury authorized and executed? What would be the impact of a compromise?
- Marketplace Security: how do marketplaces which support this protocol protect users from malicious transactions like copycat projects?
A compromise at any of these layers could render the users of even the most secure underlying platform vulnerable — anyone describing an invulnerable project is clearly wrong. Unfortunately, when dealing with a new asset class, particularly one which is growing so rapidly, there will be people working constantly to find new vulnerabilities and exploits. In such an environment, a robust understanding of these tradeoffs is critical to choosing the right platform for your project.
