Path to Permissionless node operation

From Day 1, Flow has been on a path of progressive decentralization. To date, we’ve made incredible progress and have achieved decentralization as follows:

  • Since last October, Flow community validators are currently operating 68% of consensus nodes.
  • In April, Flow debuted its first-ever community governance vote, introducing a new dynamic transaction fee structure that lowered fees for most transactions.
  • In July, Flow opened up permissionless smart contract deployment to all, with the release of Secure Cadence, a major upgrade to Flow’s revolutionary smart contract programming language (Cadence).
  • All while powering web3 experiences from Fortune 500 companies like Google and Meta, to startups collectively raising more than $4B. To date Flow has 13 million accounts, 2 million monthly active transacting users and 8,000+ developers building on Flow.

We are excited to announce one big step in that direction. As of today, anyone can now run a Flow node. We are excited to introduce a new permissionless node type called an Observer node: an unstaked node that runs on consumer grade hardware, and provides a locally accessible, continuously updated and verified copy of the block data.

With the introduction of the permissionless Observer node, the network unlocks participation opportunities for everyone. Having your own node means you don’t need to trust information about the state of the network provided by a third party, including other benefits such as privacy, security, reduced reliance on third-party servers, censorship resistance, balanced load distribution, and increased decentralization of the network.

Our progress with permissionless node operation is just beginning. We have other exciting milestones coming up by the end of this year. Permissionless deployment of staked nodes will start with Access nodes by the end of the year, with other node types to become permissionless in 2023 and beyond.

Furthermore, an additional specialized node type, called an Archive Node, will also be available by the end of the year. Archive nodes provide access to historical data which is no longer accessible via regular access nodes, as well as to be able to run Cadence scripts without being subjected to rate limits. The Archive node is a result of a community contribution from Optkat, and will also be permissionless. Read on for more information.

Observer node

An observer node is similar to an access node and provides a locally accessible, continuously updated and verified copy of the block data. It serves the gRPC Access API (support for REST API coming soon) but, unlike an access node, an observer node does not need to be staked and anyone can run it without being added to the approved list of nodes.

The observer node bootstraps by connecting to an access node and becoming part of the public network comprised of access nodes and other observer nodes. It then continuously receives blocks that are being added to the chain either directly from the access node or from other observer nodes that are part of the public network.

However, it makes no trust assumption of the upstream access node or the observer node which is providing the block and locally verifies that the blocks that are received are the correct extension of the chain e.g After receiving valid blocks A, B and C when it receives block D, it verifies that block D is indeed signed by the consensus nodes and is a valid next block.

The block data that is received is indexed and made available via the Access API. For Collection, Transactions and Account queries, it delegates those requests to the upstream access node. Similarly, transactions and scripts sent to an observer node are also forwarded to the upstream access node. Future versions of the observer node will be able to serve this data locally as well.

Since the observer node is not staked, it does not produce or execute blocks but instead serves as an unstaked access node that can be easily run on any consumer-grade computer which has enough disk space.

Observer node vs Access node

Flow has different types of nodes instead of a single validator node. Consequently, not all node types have all the data. Flow node data is divided into Protocol state and Execution state.

Protocol State is the state of the operation of the Flow network protocol, including the identity table and resources produced by nodes in the Flow network: blocks, collections, receipts, approvals, seals, etc.

Execution State is the state of Flow accounts, smart contracts, resources, etc. This state is stored in full only on Execution nodes.

The access node receives and indexes all of the protocol state data while the observer node only receives block data and delegates to an access node to serve queries for anything other than block data. So while the access node can be viewed as a read-replica for the protocol state, the observer nodes can be viewed as a local cache of the block data within the protocol state.

Who should run an observer Node?

The observer node provides an alternative to running an access node. Hence it is ideal for Dapps that need access to latest block data available locally e.g a wallet application that needs to track the latest block ID and height.

In addition to that, access node operators who want to scale their access nodes endpoints geographically can spin up geographically dispersed observer nodes which can talk to their staked access node and to each other.


In general, any consumer-grade computer with a decent network connection and sufficient disk space should be able to run an observer node.

Minimum requirements

  • CPU with 2+ cores
  • 4 GB RAM minimum
  • 300 GB SSD disk
  • 10Mbps network connection

Permissionless Access Node

To enable permissionless access nodes certain security checkpoints need to be met including baseline BFT protection against different attacks, code hardening, appropriate rate limiting and pentesting. At this time, the core protocol team is inviting bounty proposals for battle testing the feature - if you want to know more, you are invited to get in touch!

The testing is focused on the BFT resilience of the Flow networking layer and the access node gRPC endpoints.

The permissionless access node rollout will be done by putting out open slots at each epoch which can be claimed by anyone who wants to run an access node. Initially, a limited number of slots will be released every epoch, and as the testing concludes, more slots will be made available.

Archive node

The Archive node provides a scalable and efficient way to access the history of Flow protocol and the execution state for the current spork. Like the observer node, it too can be run by anyone without being staked or added to the approved list of nodes. The Archive node follows the chain, stores and indexes both protocol and execution state, and allows retrieval of blocks, collections, transactions and events from the genesis of the current spork.

It also allows script execution and other read-only queries that require the execution state to be read. It can answer any queries from past data e.g. “what was the Flow account balance at height X?”, where X is several thousand blocks in the past.

Who should run an archive node?

  • The archive node supports Cadence script execution out-of-the-box and can be used to execute arbitrarily complex scripts without being subjected to rate limits or timeouts. Hence, read-heavy applications that execute a lot of complex or long-running scripts can execute those on the archive node instead of sending them over to an access node e.g. an application that tracks account balance.
  • The archive node maintains multiple specialized indexes for different purposes. Contrary to the execution node’s state trie, the index for ledger registers allows random access to the execution state at any block height which enables state retrieval at any point in history, overcoming the pruning limit currently seen on the execution node. Hence, applications that require access to old execution state beyond ~300 blocks in the past, such as chain analytics, can query an archive node.


The archive node will be consuming large amounts of data (100s of GBs) and requires a machine with large disk space.

Archive node will consume hundreds of gigabytes of data and currently will hold the entire execution state in memory. While this will be improved in the future, archive nodes will currently require powerful memory-optimized machines for operation.

Minimum requirements

  • 40 CPUs
  • 800 GB RAM
  • 1TB disk space
  • 1Gbps network connection

Planned milestones for Fall 2022

Following are the planned milestones in the coming weeks and months:

Milestone Schedule Date Status
Observer node launch August 2022 Launched
Launch of permissionless access node Early Q1 2023 (updated) In progress
Completion of pen testing Late H2, 2022 In progress
Second set of permissionless access node slots Q1 2023 (updated) In progress
Archive node 2023 (updated) In progress
Access node and Observer node integration with the archive node to query the archival node for state-related queries (account, events etc.) and to execute scripts 2023 (updated) In progress
Launch of Permissionless deployment for other staked node types 2023 and beyond Not Started

Compare and Contrast

Current Access Node Permissionless Access Node Observer node Archive node
Description Same as current access node but permissionless Subset of the access node, permissionless and not staked Access node plus a node that can serve execution state and execute scripts
Staked (Part of the identity list) :white_check_mark: :white_check_mark: :x: :x:
Permissionless (no need to add to the approved list on-chain) :x: :white_check_mark: :white_check_mark: :white_check_mark:
Limited/unlimited numbers can be spun up Limited Limited Unlimited Unlimited
Part of the Flow network (talks to other staked nodes) :white_check_mark: :white_check_mark: :x: (only talks to a staked AN and other observer nodes) :x: (only talks to a staked AN)
What data does it serve? Protocol data (i.e. blocks, transactions, collections) Protocol data Protocol data, Blocks from the local store, everything else (collections, transactions etc.) proxied to access node.
When launch? Early Q1 2023 (updated) Aug 2022 Late H2