We manage your security to weather the AI storm →

← Resource Hub

Launching Your Own Blockchain: The Security Decisions

By Owen Thurm Published 6 min read

Launching Your Own Blockchain: The Security Decisions

Quick answer. Four decisions: who runs consensus or sequencing, who holds upgrade and pause keys, how the bridge verifies messages, and who runs the infrastructure. Then spread operators, delay upgrades, monitor privileged actions and rehearse a chain halt.

Watch: Launching Your Own Blockchain: The Security Decisions 1:36
Video transcript

A company that launches its own blockchain takes over the security that apps normally inherit. Four decisions matter most: consensus or sequencing, upgrade and pause keys, the bridge, and infrastructure.

First, layer 1 or layer 2. On your own layer 1, your validators order and settle everything. On a layer 2, Ethereum settles through a proof system, and the risk shifts to upgrade keys.

Tempo halts if more than one-third of its validators go offline. Your validator set is your security boundary, so count independent operators, not keys.

Ronin's bridge needed five of nine validator signatures. Sky Mavis ran four, and an allowlist entry that was never revoked gave the attacker a fifth.

On a layer 2, keep cold upgrade keys in multisigs of independent signers. Keep hot batcher keys in an HSM. Add a timelock so users can leave first, and test sequencer failover.

In the 2022 BSC Token Hub exploit, Rekt valued the minted BNB at about 586 million dollars. Cap minting per hour, reconcile supply continuously, and give the bridge its own pause.

Decide in advance who can halt the chain. Write runbooks, name who decides and who signs, rehearse on a testnet, and record every decision for regulators.

Guardian reviews chains before launch, from signing models to pause paths. Read the full article, or book a system review call with a Guardian engineer.

Payment and trading companies now run their own chains:

  • Tempo, incubated by Stripe and Paradigm, is a payments-first layer 1.
  • Arc, from Circle, is a layer 1 that uses USDC as gas.
  • Robinhood Chain is a layer 2 built on Arbitrum Dedicated Blockchains.

Running a chain makes you the operator of security that apps normally inherit. For a side-by-side of the payment chains, see stablecoin chains compared.

L1, L2 or Appchain

The first decision sets who you, your users and your partners must trust.

Own layer 1Layer 2
Who orders transactionsYour validatorsYour sequencer
Who settlesYour validatorsEthereum, through a proof system
If operators failA BFT chain haltsUsers force transactions in through Ethereum
Main riskValidator collusion or compromiseUpgrade keys and the proof system
ExamplesTempo, ArcRobinhood Chain

An appchain can be either: a layer 1 for one product, or a layer 2 on a stack such as OP Stack or Arbitrum.

A rollup's protections depend on how far it has decentralized. See rollup stages explained before you promise users anything.

Validators and Consensus

BFT chains stop when too many validators go offline. Tempo's docs say it keeps finalizing while two-thirds of validators are online and honest, and halts if more than one-third go offline.

So the validator set is your security boundary. Tempo's active set is permissioned. Arc names a founding validator cohort that includes Visa, Mastercard and Standard Chartered.

Count independent operators, not keys.

Ronin's bridge needed 5 of 9 validator signatures. Sky Mavis ran four, and an allowlist entry that was never revoked gave the attacker a fifth.

Nobody noticed for six days, Rekt reported. A user who could not withdraw raised the alarm.

The decisions to make before launch:

  • Spread validators across organizations, clouds and regions.
  • Keep validator keys in HSMs, apart from the machines facing the network.
  • Write down how validators are added or removed, by whom, and with what delay.
  • Run more than one client implementation where one exists.
  • Alert on missed blocks, double signing and validator-set changes.

Client diversity matters because one bug can hit every node running that client. On Ethereum, ethereum.org says a bug in a client with over a third of nodes could stop finality.

With two-thirds, it could finalize the wrong chain.

Sequencer and Upgrade Keys

On a layer 2, a few roles carry most of the risk. OP Stack documents them:

RoleWhat it doesIf compromised
L1 ProxyAdmin ownerUpgrades system contractsMalicious upgrades; bridge funds removed or locked
System Config ownerSets chain parametersTemporary outage; users overcharged
Batcher (hot key)Posts transaction batchesL2 reorgs or sequencer outages
Proposer (hot key)Proposes state rootsInvalid withdrawals after 7 days, if unchallenged
Guardian (an OP Stack role)Pauses withdrawalsWithdrawals paused for up to 3 months

On Optimism-governed chains such as OP Mainnet, the ProxyAdmin owner is a 2-of-2: an Optimism Foundation 5-of-7 multisig and the Security Council.

Arbitrum chains route the same power through an Upgrade Executor. Its chain owners can upgrade core contracts, set system parameters and add or remove owners.

If an OP Stack sequencer stops, users can send transactions through Ethereum. They are processed within the sequencer window, 12 hours by default.

The decisions:

  • Cold keys: upgrade and config roles in multisigs of independent signers on hardware wallets.
  • Hot keys: batcher and proposer keys in an HSM or cloud KMS, with a rotation plan.
  • Delay: a timelock or exit window on upgrades, so users can leave first.
  • Liveness: a high-availability sequencer with a failover you have tested.

On a layer 1, protocol changes ship as client releases that validators adopt. Protect release signing and build pipelines like upgrade keys.

Bridges and Messaging

A bridge acts on messages from another chain. Whoever can forge or sign those messages can mint or release funds.

In October 2022, an exploit of BSC Token Hub, BNB Chain's cross-chain bridge, "resulted in extra BNB," Binance's CEO said. He estimated the impact at about $100 million at the time.

Rekt valued the 2 million minted BNB at about $586 million; about $127 million was bridged to other chains.

A rollup's canonical bridge inherits its proof system and upgrade keys. Tokens arriving through a third-party bridge inherit that bridge's verifiers instead.

  • Choose verifiers run by independent parties, with no shared keys or cloud accounts.
  • Cap how much can be minted or released per hour.
  • Reconcile supply on both sides continuously, and alert on any gap.
  • Give the bridge its own pause, held apart from upgrade keys.

For how bridges fail, see cross-chain bridge security and the biggest bridge hacks.

Infrastructure and Incident Response

Infrastructure

Users reach your chain through RPC endpoints, explorers, bridge front ends and DNS. Your sequencer and batcher keys sit online in your cloud.

  • Run your own RPC nodes and at least one independent provider.
  • Keep signing keys in separate cloud accounts with least-privilege access.
  • Lock domains at the registrar, and watch DNS and certificates.
  • Alert on stalled blocks, finality lag, reorgs and batch-posting gaps.

If you change the EVM, every change needs its own review. See our custom EVM audit guide.

Incident response

Decide in advance who can halt the chain, pause the bridge or ship an emergency release.

After the BSC Token Hub exploit, Binance asked all validators to temporarily suspend BNB Smart Chain. Rekt says it was paused for about 8 hours.

Validators brought it back on a new release, which The Block said would disable native cross-chain communication.

That power protects users. It is also a trust assumption that partners and regulators will ask about.

  1. Write runbooks for a halt, a bridge pause and an emergency upgrade.
  2. Name who decides, who signs and how they are reached at 3 AM.
  3. Rehearse each one on a testnet before mainnet.
  4. Record every incident and decision for partners and regulators.

How Guardian Helps

Guardian's advisory work covers which chain and why, the custody and signing model, and the upgrade and pause paths you will need on your worst day.

Around the launch:

  • Pre-production reviews for new protocols, markets, chains and token systems.
  • Automation pentests for keepers, relayers, bots and threshold signers.
  • Infrastructure pentests for cloud accounts and vendor consoles.
  • For fintechs, Managed Security to keep controls in place as you grow.
  • A trust center: one page on what was reviewed, the controls and what is still open.

To start, book a system review call: an hour with a Guardian engineer on what you run and who holds the keys.

Frequently Asked Questions

Should a company launch a layer 1 or a layer 2?

A layer 1 gives full control of validators, fees and rules, but you secure consensus yourself. A layer 2 settles to Ethereum and lets users force transactions in, but you hold sequencer and upgrade keys.

Who controls a corporate blockchain?

Whoever holds the validator set, the sequencer and the upgrade keys. Tempo's validator set is permissioned, and on Arbitrum chains, chain owners can upgrade core contracts. Publish who holds each power and how changes are delayed.

What is the biggest security risk when launching a blockchain?

Concentrated keys. Ronin's bridge fell when an attacker gained five of nine validator signatures, four of them run by one company. Spread operators, protect upgrade and bridge keys, and monitor every privileged change.

Can a company halt its own blockchain?

Often, yes. In 2022, Binance asked validators to suspend BNB Smart Chain after a bridge exploit. On OP Stack chains, a role called the Guardian can pause withdrawals. Decide in advance who holds that power and how users are told.

Sources

Secure your chain before it launches

Guardian reviews new chains before launch and tests the infrastructure around them, then keeps your controls in place as you grow.