to support community collaboration


The Flow team is excited to share community-focused Flow ecosystem priorities. Since the launch of The Flow blockchain in December 2020, multiple independent teams from various disciplines ranging from distributed systems to programming languages, cryptography, and game theory are constantly advancing the research and development of Flow. Flow’s ecosystem has grown from a small group of enthusiasts to a global community of over 10,000 developers, over 17 million user accounts, and over 2 million monthly active wallets.  

An integral part of continuing the decentralization of Flow is collaborating with our community on how core elements of the network are built. To make it easier for Flow to collaborate across entities, different working groups exist for various focus areas. These groups enable teams in the community to contribute to different components in parallel and scale coordination more efficiently. The collaborative plan is executed by contributors worldwide, including but not limited to Dapper Labs, Graffle, Coinbase Cloud, Blocto, Lilico, Outblock, GetBlock, academic institutions, including the University of Waterloo and the University of BC, and other independent researchers. 

Ecosystem Priorities

The ecosystem priorities have been organized into several focus areas. Each area has a set of deliverable outcomes. Here you will find an overview of key improvements expected in each area and descriptions of the core functional components, links to associated academic research, status updates, and core contributors. 

Developer Tooling & Ecosystem

  • Increase developer productivity
  • Make developer onboarding faster and easier 
  • Enable engaging native consumer experiences on mobile
  • Unlock progressive user onboarding with world-class mainstream experience
  • Demonstrate service-less dapps to eliminate platform risks, create trust, and unlock new experiences
  • Improve the developer ecosystem through community contributions

Cadence Smart Contract Language

  • Make performance improvements
  • Enable long-term support (write once, run forever)
  • Provide support for compilation

Smart Contract Ecosystem

  • Showcase Cadence’s unique characteristics and strengths 
  • Foster community engagement and adoption of standards

Core Protocol Operations

  • Improve performance and scalability 
  • Achieve zero downtime rolling upgrades of protocol 
  • Nurture a scalable peer-to-peer network for data retrievability
  • Improve byzantine fault tolerance [BFT]
  • Improve runtime resilience of consensus
  • Support permissionless node operations
  • Introduce a new staked node operator selection algorithm
  • Support for massive state sizes
  • Integrate cryptography advancements

Protocol Economics

  • Implement protection against state bloating 
  • Move to new gas metering for enhanced network security
  • Revisit FLOW issuance rate
  • Decrease barriers to entry with lower staking requirements

Protocol Governance

  • Increase participation in the Flow Service Account process
  • Automate network operations: performance-based node rewards and slashing
  • Present new governance proposal and voting process

Focus Areas Deep Dive

Developer Tooling & Ecosystem 

The Developer Tooling & Ecosystem working group is focused on making Flow the most user-friendly Web3 developer platform. Success for this group will translate into higher developer satisfaction, reduced friction, and ultimately more applications launched on Flow.

Increase developer productivity

Flow requires robust tools that support the most important developer environments, simplify the development lifecycle, enable fast iterations, and increase developers’ confidence. This area focuses on improvements to various tools, including SDKs, libraries, CLI, Emulator, and the VSCode Extension. Specific projects include, but are not limited to:

Faster & easier developer onboarding

Developer education is critical to onboard millions of Flow developers. There is a need to build best-in-class documentation and samples, and a cutting edge developer playground. This requires understanding developer journeys and information architecture as much as the content. Priorities for this working group are:

  • Using sample projects to highlight composability through on-chain logic

Enable engaging native consumer experiences on mobile

Mobile applications have the potential to increase user engagement and reach mainstream consumers through app stores. With Flow, mobile developers can improve security through support for Secure Enclave & Keystore, minimize their needs for backend service by building on-chain logic, and ramp up quickly to Cadence – Flow’s smart contract language inspired by modern languages like Swift and Kotlin. This focus area is concerned with bringing the value proposition to light by

Unlock progressive user onboarding with world-class mainstream experience

The self-custody is perhaps the single most important feature of a web3, but the next billion blockchain users don’t have self-custodial wallets yet. Flow has the potential to unlock the real barrier to mainstream adoption, which is first-time user experience (FTUE). For most new users, the crypto scene currently feels a bit like the wild, wild west. There is a myriad of situations where they are uncertain of how to interact with the wallet and they lack trust and security in the services they are attempting to use.  Flow needs to provide tooling for developers to onboard users with wallet-less onboarding via email or social identities so they can get immediate value seamlessly and then upgrade to self-custody when they’re ready or as the app demands it.

Demonstrate Flow’s unique value proposition through on-chain gaming

Demonstrate service-less dapps to eliminate platform risks, create trust, and unlock new experiences

Flow was designed to enable new experiences through composable building blocks that improve transparency. Getting more on-chain logic on Flow is critical to enable this future. Flow’s account model, modern smart contract language, and multi-node architecture enable on-chain mechanics with great user experiences without needing backend services. This focus area will use gaming as the primary use case by delivering:

  • Native SDKs for .NET, Unity, and Unreal
  • Sample contracts demonstrating on-chain game mechanics
  • Non-custodial wallet support to securely sign transactions without prompts during gameplay 

Improve the developer ecosystem through community contributions

Flow is building a vibrant ecosystem of builders to fill essential web3 building blocks, like tools and services. The Developer Grants program is allocating FLOW tokens to support the development of these ecosystem gaps. 

Some of the projects listed above are driven by Flow community members who received grants to support their efforts.

If you are interested in participating in the program, you can:

  • Review wishlist items and submit a proposal, as these are important ecosystem gaps that have been identified and need a solution.
  • Submit a wishlist item for a gap that you have identified. You don’t need to work on it yourself, but you can help identify others who can/will.
  • Review proposals submitted by others in the community by upvoting or commenting on the GitHub issue. More feedback from the community is always helpful.


Flow contributors include: Bjarte Karlsen, Alexander Zwerner, Matt Hichana, Tyron Brand, Maggo, Emerald DAO, Inconfido, Flowser, Outblock, GetBlock, SoulMade, Dapper Labs, Dev Spotlight & independent researchers. The working group is building in public and coordinating via the Developer Grants program and GitHub.


flow icon

Cadence Smart Contract Language

The Cadence Language working group is focused on all things related to the smart contract language experience, including interactions with the account storage, security, and scalability of the network. Focus areas are designing, developing, and optimizing smart contract language and Flow virtual machine (FVM). 

Long-term support: write once, run forever

One of the top priorities for Cadence is to design and implement the first stable and long-term-supported release of Cadence (aka Stable Cadence). This would be a long-term process in which Cadence achieves feature completeness, the core smart contracts are sufficiently battle-tested, and the economics of the system are sufficiently understood to provide long-term support without suffering from any breaking changes and maintenance issues. Based on the feedback from the community so far, this milestone was separated into two phases:

  • Secure Cadence: focused on security hardening, which unlocked permissionless smart contract deployment
  • Long-term support: focused on usability improvements that will require breaking changes. For example, he changes may include streamlined token standards, improved capabilities, and removal of reentrancy “foot-guns.”

If you have any thoughts or questions about the overall idea of Stable Cadence, please comment on the blog post or participate in Cadence FLIPs on GitHub.

Performance improvements

The Cadence Language working group is collaborating with the Core Protocol working group to achieve the goal of 1000 transactions per second (TPS). There are several workstreams currently under development or consideration:

  • Cadence external value encoding optimizations will include adding an alternative to the existing JSON-based encoding for external Cadence values. This new encoding will improve the speed of encoding/decoding, reduce the size of payloads that transfer Cadence values, and unlike the JSON-based encoding, will have a canonical form. It will also enable storing type information on-chain, avoiding repeated parsing and type-checking of Cadence types during execution
  • FVM programs cache optimizations will improve the performance of loading contracts during execution. Number of optimizations are being evaluated, including cache invalidation and storing parsed and type-check contracts on-chain
  • FVM pre-execution pipelining can improve the speed of execution by parsing and type-checking transactions in parallel while a transaction is executed, and following transactions are already parsed and type-checked
  • Elaboration optimizations will include finding a better representation for elaborations, as well as making elaborations serializable so they can be stored on-chain

Support for Compilation 

Cadence compilation will be a long-term investment that we will build in stages to deliver several benefits, including

  • Performance improvements
  • Currently, transaction execution is implemented using a tree-walking interpreter, which is not designed for high performance. Switching to compilation has the potential to unlock performance improvements orders of magnitude above current levels.
  • Allow the language to evolve independently of the VM so changes to the language can be rolled out more quickly in a backwards compatible manner.

The first few milestones should focus on the performance benefits of on-chain compilation, specifically the execution of pre-compiled contracts and evaluation of potential performance impacts of a parallel compilation of transactions.

If you have any thoughts, use cases, or questions regarding the Cadence experience, please participate in the open design meeting or use this Discord channel.


The current chair of the Cadence working group is Bastian Müller and the core contributors are Dapper Labs, NCC Group, Halborn and other independent contributors. The working group is building in public and coordinating via monthly public language design meetings, GitHub, and community FLIPs.


flow icon

Smart Contract Ecosystem

The Smart Contract Engineering group is focused on all things related to applied design, architecture, and security considerations when using Cadence for developing decentralized applications on Flow. Specifically, the group supports the evolution of contract standards and the establishment of design patterns, guidance and methods for composability and other best practices around extensibility and security.

Showcasing Cadence’s unique characteristics and strengths

Cadence brings together several novel programming concepts in the context of decentralized application development which can be challenging for builders to understand and adjust to. Lowering these barriers through improved documentation, examples/prototypes, online articles and other research and development (R&D) expands the Cadence knowledgebase and adoption. Current priorities include:

  • Documenting how Cadence improves support for building secure and composable dApps compared to other smart contract alternatives for Web2 adopters
  • Providing advanced examples of Cadence usage across a range of domains and verticals that bring home the full potential of capability-based security, resource-oriented concepts, and the account model

Community engagement and adoption of standards

The Smart Contract Engineering group collaborates with stakeholders from across the community and Dapper Labs to establish new standards (i.e. NFT Storefront v2, and to support new proposals for standards over time.

The group works to ensure the engagement of stakeholders throughout the development of solutions such as standards, patterns, or models that simplify the work required of builders and strengthen the network effects of Flow. Efforts currently under development or consideration include:

  • Version Two (V2) Fungible Token and Non-Fungible Token standards: Involves ongoing development and discussion with the community
  • Offers standard: Will be presented as a community standard soon
  • Dynamic NFTs: R&D development to establish best practice patterns for dynamically mutable NFT metadata from the authorized external account
  • Dapp account security model: R&D development to showcase capability-based model for keyless, securely scoped, multi-account mutability on sub-accounts
  • On-chain contract based games: R&D development to showcase how to build interactive, 100% on-chain games
  • Capabilities for AuthAccount: Involves ongoing proposal discussion
  • Scoped AuthAccount: Community proposal for enabling apps and users to define rules permitting or preventing withdrawal of sensitive resources
  • DeFi swap standard: Standards FLIP, to be proposed
  • Oracle standard: Standards FLIP, to be proposed


The value of any standards, patterns, or practices to the ecosystem depends significantly on adoption rates, without which network effects remain muted. As such, this group also focuses on ensuring as smooth as possible onboarding to standards for the community. Current focus areas include: 

  • Adoption of published standards to Dapper contracts across all products and tooling
  • Implementation of a V2 NFT storefront standard offering migration guidance to smooth marketplace adoption 
  • Implementation of an offers standard, with Dapper wallet integration planned


The current chair of the Smart Contract engineering group is Josh Hannan and the core contributors are Dapper Labs and other independent contributors. The working group is building in public and coordinating via monthly Smart Contract Open House meetings, GitHub and community FLIPs. 


flow icon

Core Protocol Operations

Protocol working group responsibility is dedicated to the security, scalability, progressive decentralization, and maintenance of the different subsystems of the protocol.  

It operates at the intersection of distributed byzantine fault tolerance systems, protocol economics, Cadence smart contract language, and Governance.

Performance and Scalability Improvements

One of the top priorities is to improve the network throughput TPS to better support the growth and adoption of applications with high transaction volume. While increasing throughput is critical, it is essential that results from achieving this goal remain decentralized and secure. It's imperative that any performance gain does not raise the barrier to entry for node operators.  

There is sufficient low-hanging fruit in the performance realm to expect 1000 TPS in the near future. The Core Protocol working group is focused on several workstreams:

Another important priority for the core protocol is improving the scalability and performance of the execution storage. These workstreams are being prioritized to tackle the long-term state bloating by:

  • Reducing memory and disk usage by optimizing and compressing stored cadence and FVM values, improving the structure of the merkle tree
  • Optimizing storage operation performance by minimizing bytes read/written during a transaction through consolidating stored values based on the access patterns (e.g. improvements to the Atree)
  • Reducing proof sizes and memory usage by reducing the depth of the merkle trees using alternative cryptographic solutions (e.g. vector commitments) 

Zero-downtime rolling upgrades of the protocol

Software upgrades and maintenance are an inevitable part of any decentralized service, and for Flow, these are achieved via “sporks.” A spork usually happens about once every two months, currently with a temporary downtime of roughly 90 minutes. Community node operators and the protocol engineering team are responsible for improving the network uptime, reducing spork maintenance windows and getting to the state of rolling upgrades with zero downtime. The current goal is to move toward a zero downtime protocol upgrade when no data migrations are required, which normally only occur when the data format has changed. This can be achieved through a height coordinated protocol upgrade, similar to strategies used by other chains. In the near term, a spork may still be required until the height coordinated upgrade process matures and if there has been an update to data storage format. Because of this, the current migration and sporking process are also being optimized, and it should be possible to spork within a 30-minute period when a spork does not involve any data storage format upgrade. Reducing spork frequency to every quarter plus frequent rolling upgrades will ensure that the protocol is providing more seamless upgrades without compromising the pace of innovation. 

The Core Protocol working group is working on more concrete ideas for achieving zero-downtime state migrations and will update this page at an appropriate time. 

Scalable peer-to-peer network for data retrievability

At the moment, Flow's core protocol does not specify any means for permanently storing all of the execution state changes that it commits over time. The amount of data is too large to achieve this, plus it would be a waste of valuable on-chain storage for storing historical data. Introducing observer and archival nodes would allow users to extract data locally for archival and verification purposes. Still, there is a need for an economically viable solution to access historical data without running a full archival node, which currently requires full data center grade hardware. There are a few ideas on who will store the historical data including: 

  • Incentivized marketplaces in decentralized protocols that can provide historical data with merkle proofs 
  • Managed service platforms like Coinbase Cloud, Block Daemon, Quicknode, Infura that can run archival nodes
  • Clients in a peer-to-peer (P2P) network that could store random portions of chain history. All clients in this voluntary P2P network provide the data and functionality necessary to expose the standard gRPC & REST API 

The P2P network can be designed to ensure that clients participating in these networks can do so with minimal networking bandwidth, CPU, RAM, and HDD resources. In the short term, historical access can be provided by Dapper Labs’ archival nodes. However, in the mid to long term, serving historical access through other protocols or community incentives will be more efficient. 

We invite the community to propose additional features for Flow’s execution-state sync protocol. The goal is to enable valuable add-on services utilizing the execution state that are beyond the scope of the core protocol but require (small) additional protocol functionality to be implemented. The community can contribute to this workstream via the Flow developer grants program. If you would like to contribute, please get in touch.

Improve byzantine fault tolerance

Byzantine fault tolerance [BFT] refers to the network's ability to securely operate even in the presence of actively malicious (aka byzantine) nodes in a decentralized network, which is key to unlocking permissionless node operations. It necessitates that all nodes must be resilient to any conceivable malicious actions originating from the permissionless nodes. BFT can be partitioned into three classes of attacks: message-level attacks (including impersonation or masquerade attacks), protocol-level attacks (multiple individually-valid messages constitute a protocol violation), and spamming

As a first step, a network-wide framework for mitigating impersonation or masquerade attacks needs to lay the foundations. A new BFT protocol for execution-state replication will complement the network's protection and close the remaining surface for protocol-level attacks by Access Nodes, Observer Nodes, and Archival Nodes, thereby enabling their permissionless operation. 

In later steps, core contributors should focus on further hardening the execution-state replication protocol against large-scale spamming and DDoS attacks, thereby allowing us to further increase the number of permissionless Access, Observer, and Archival Nodes.

At this time, the Core Protocol working group is seeking peer reviews for the execution-state-replication protocol for spamming vulnerabilities. 

Improve runtime resilience of consensus

Flow uses HotStuff, a leader-based consensus algorithm. Over the last two years, considerable research advancements have been made in this domain. Specifically, the Jolteon protocol (June 2021) improves on the original HotStuff [v6] in two important areas: 

  • On the happy path Jolteon only requires two additional rounds to finalize a block (vs 3 for HotStuff v6)
  • Jolteon incorporates a PaceMaker 

Jolteon's PaceMaker utilizes dedicated messages for BFT view synchronization, which substantially improves the protocol's resilience to a broad class of failure scenarios, including successive leader failures, network partitions, unfavorable bootstrapping conditions, etc. Jolteon's key advancements have also been adopted by the Diem team (formerly Facebook) resulting in DiemBFT v4 (August 2021)

After a comprehensive review of cutting-edge approaches, the Core Protocol team has decided to adopt Jolteon (with some minor revisions). Furthermore, the PaceMaker-generated Timeout Certificates are also a prerequisite for byzantine-resilient Epoch switchover in Flow. The research and implementation are already ongoing since the beginning of the year. 

At this time, the group is inviting help to further modularize the Flow protocol code base. A standalone consensus implementation for research purposes that shares the code base with Flow's production implementation would be particularly helpful (see details here). Furthermore, we are grateful for contributions from the academic community regarding the optimal parametrization of the Jolteon PaceMaker (see details here). 

Permissionless Node Operations

The goal is to be fully permissionless for all node types, but the network can enable active ownership with an increasingly broad set of community node operators through progressive decentralization and a stepwise process. In short, we are committed to fully empowering any willing participant to contribute and benefit from their efforts within the Flow ecosystem. This is accomplished through progressive decentralization — a process in which we will relinquish control by degrees over time. Taking a step-by-step approach allows us to focus and create a path toward a secure network.

With the introduction of the Observer Node and, soon, the Archival Node, the network unlocks participation opportunities for everyone without any staking. Having your own node means you do not have to rely on third parties for the state of the network. You may not reap the same financial gains as the fully-staked nodes but you may see other benefits such as privacy, security, balanced load distribution, reduced reliance on third-party servers, and network decentralization.

The permissionless node operations for a staked Access Node will need a new operator selection algorithm that is transparent to the community. Extensive research has gone into implementing byzantine fault tolerance [BFT] protection against any attacks that may arise from a permissionless byzantine actor in the ecosystem. This workstream can unlock permissionless operations for other node types (Verification, Collection, Consensus) in the future. 

At this time, the working group is seeking peer review and inviting bounty proposals for battle-testing the feature. If you want to know more, you are invited to get in touch

Introduce a new staked node operator selection algorithm

Historically, to become a node operator, you would need to ensure you meet the minimum staking and the program requirements to be approved. While this manual process ensured the continued security of the network, the amount of $FLOW required to be eligible to become a staked node operator was extremely high, which ruled out many aspiring operators. The selection process also lacked transparency to the public. Flow should introduce a process of node operator selection which can relinquish control by degrees over time. This can be done in two steps: 

  1. The introduction of automated slot assignment (staking slots)
  2. Reducing the minimum staking requirements

The idea of staking slots is to build an automated process for including new nodes in the staking table while managing the max number of nodes per node type. This process can be extended in the future with an auction mechanism for selecting node operators in a fully permissionless way. 

Reducing minimum staking requirements is still under research to ensure the stake is high enough to not compromise the network's security. 

Support Massive State Sizes

Flow’s execution state is stored in a merkle trie data structure. The current implementation of this in the Flow node software, called mtrie, resides fully in-memory and is optimized for high-performance applications on Execution nodes. Since the execution state is very large, there is a tradeoff between performance and node hardware requirements. As a result, Execution nodes require large amounts of memory (512 GB of RAM) to store the entire trie plus a small amount of history fully in memory.

For other applications like Archival nodes, storage capacity and relaxed hardware requirements are more important than performance so a scalable trie optimized for large data sets is desired. This would allow for nodes running on consumer-grade hardware but with large disks.

We would like to invite community contributions to this workstream via the Flow Developer Grants program

Integration of Cryptography advancements
Currently, the core group is hardening the implemented cryptography primitives and protocols further to improve the byzantine fault tolerance of the chain. Such improvements include integrating the proof of possession (PoP) of the BLS private key of node operators into the staking process. PoP is the defense chosen by the protocol to secure the multiple BLS signature aggregations and the BLS-based SPoCK scheme. BLS signatures and BLS-based threshold-signature implementations are continuously being updated to include the latest performance advancements and improve their standard compliance. The Pedersen-based distributed key generation of the random beacon is also being updated to be more resilient against malicious behaviors. 

Moreover, the protocol attempts to use a few additional cryptography research areas to improve the chain's security and performance. One such area is the BLS-based Specialized Proof of Confidential Knowledge (SPoCK), which is being extended to support aggregations and optimize the protocol's sealing mechanism.

Other possible research topics include exploration into crypto accumulators and vector commitments.


The current chair of the Core Protocol working group is Alex Hentschel and the core contributors are Dapper Labs, Coinbase Cloud, NCC Group, Halborn and Metrika. The working group is collaborating in the Core Protocol GitHub and in the near future will host a public R&D meeting to discuss updates to work streams, cross-functional brainstorming, and receive feedback from one another.


flow icon

Protocol Economics

The Protocol Economics working group is responsible for the token economy, which optimizes token distribution, governance, and security of the Flow network. The group works towards designing incentive systems that reward users for adhering to the publicly stated rules of the network and penalize them for inappropriate behaviors. The group relies on mathematics, game theory, and economic theory to improve the design of staking, delegation, transaction fees, token distribution, and monetary inflation. 

Protection against state bloat 

Flow has a multi-node architecture where all nodes specialize and fulfill a specific role in the operation of the network. Execution nodes (ENs) maintain state computation and have a cryptographically verifiable data store for all user accounts and smart contract states. However, other node types in the network – Collection, Consensus and Verification nodes – do not deal with state concerns. With this separation of roles and concerns, state bloating has been isolated to a handful of ENs that can scale independently without impacting other nodes in the ecosystem. ENs store the account state along with 100 previous blocks, exerting pressure on the actual storage requirements as new accounts and smart contracts on the network grow. 

Storage fees were implemented to regulate the state's growth, limiting the maximum amount of storage each account could use. This incentivizes developers to use on-chain storage efficiently and avoid storing unnecessary data. While ‍the minimum balance has been extremely low (0.001 FLOW) in the network's early onboarding days, the working group must revisit the storage pricing to account for current and future state growth. Any storage fee changes must be carefully executed to minimize the impact on Dapps in production and to nurture Flow as a cost-effective platform for future developers. This part of the ecosystem is under consideration and we will update this page at an appropriate time. 

New transaction fees metering for enhanced network security

Recent work around segmented transaction fees introduced variable execution fees, which ensure fair pricing based on the impact on the network. For instance, heavier operations will require more resources to process and propagate transactions.

Similarly, this working group can explore and test a new model to enhance network security for spamming attacks with variable inclusion fees and surge pricing. A network surge may be applied when the network is either under pressure due to:

  • Demand: An increased influx of transactions that require processing 
  • Supply: A reduced ability to process transactions 

Currently, the network surge factor is fixed at 1.0. Costs for inclusion will be impacted by the byte size of the transaction and the number of signatures required. Most importantly, the fee-management experience for developers must remain intuitive and the network should continue to offer high throughput and scalability, such that Flow endures as a cost-effective platform for developers.

Revisiting FLOW issuance rate

Flow, like many other blockchains, uses protocol-level rewards paid to the operators of nodes in its network. The original FLOW Token Distribution plan detailed a strategy of using 5 percent token rewards for the first 18 months, then suggested adjusting the rewards rate as decided by the community. Given the current macroeconomic headwinds faced by the industry and global economy, the Flow team released a proposal suggesting that the 5 percent inflation remains unchanged. 

Flow faces the classic trade-off of minimizing the inflation rate to reduce the implicit cost of holding FLOW tokens with synchronously incentivizing the node operators to run nodes via sufficient rewards. The network must balance transaction fees, new token issuance, the minimum stake required to be a node operator, and the number of nodes in the system. All things considered, this part of the ecosystem is under consideration, and the page will be updated at an appropriate time.

Lowering barriers to entry with lower staking requirements

While no single node is solely accountable for the network’s overall security, node operators are mandated to stake minimum financial security comprised of FLOW tokens for a protocol-defined lock-in period to disincentivize faulty behavior. For node operation to be an accessible and rewarding activity, the current minimum staking amounts must be revisited. First, the team would undertake a practical analysis of operator COGS over the last two years. Then, through a democratized process, decisions on the new staking thresholds would be made to maintain network security and promote decentralization, while making it worthwhile for operators to participate across different node roles.

At this time we are inviting other node operators to share their COGS analysis through this publicly visible forum.


The core contributors for this working group include entrepreneurial support organizations, non-profits, Dapper Labs and academic institutions including Berkeley, Purdue, UC Davis, and Rochester Institute of Technology. Any proposed protocol economics improvements are collaborated in public using Governance FLIPS. And in the near future will host a public R&D meeting to discuss updates to work streams, cross-functional brainstorming, and receive feedback from one another.


flow icon

Protocol Governance

For Flow to continue toward progressive decentralization, it will require not only the distributed infrastructure but also the capacity to be maintained and governed over time by more node operators. The Protocol Governance working group operates at the intersection of all the other groups and is responsible for the development and governance of the network. This group is responsible for technical governance, which includes updating system parameters, rolling out larger-scale changes in the protocol, and fixing bugs.

Increased participation in the multi-sig process

With weekly improvements to the multi-sig signing of Flow transactions, processes, and automated network operations, it has become possible to expand the number of signers for multi-sig operations on Flow accounts. The Flow multi-sig signers should be from across the ecosystem and have an interest in the long-term development and health of Flow. Currently, two main accounts are used to manage parts of the protocol: 

  1. Service account: For items related to protocol parameters
  2. Staking account: Used to hold resources related to staked nodes within the network

Automated network operations: performance-based rewards & slashing

The staking reward system is ready to have automation turned on. Doing this will reduce the number of weekly transactions from the service account and improve the predictability of payment timing for stakers and delegators. With automation enabled, the service account can focus on less frequent transactions such as changing fees and assisting in sporks.

As the network matures, operations such as slashing validators for policy violations should be increasingly automated. Work can begin on slashing systems as well as validator payouts based on work done instead of simple staking. These ideas have yet to be formalized or implemented. We look forward to community involvement in the design of these features.

Governance Proposal process

Flow Governance needs to expand its use of FLIPS to gather feedback and communicate governance priorities. Governance FLIPs will provide a standard mechanism for community members to propose changes actions taken by the Flow Service Account signers, execute certain actions such as adding and removing node operators, and proposing changes to Flow’s fee structures.


The core contributors include Dapper Labs, Blocto,, Outblaze, Animoca. Anyone is welcome to contribute to governing the protocol and community efforts. For more information please refer to the FLIPs repository and the Flow Governance Forum. And in the near future will host a public R&D meeting to discuss updates to work streams, cross-functional brainstorming, and receive feedback from one another.


flow icon

Publishing ecosystem priorities quarterly

Flow is approaching a pivotal point with faster ecosystem growth and contributions to multiple working groups as it continues to grow and mature. Going forward, the Flow team will release blueprints of ecosystem priorities on a regular quarterly cycle. This document of ecosystem priorities will always be a work in progress — a living document. By making information more accessible and organized, we can reduce the threshold for contribution and make collaboration easier.

If there is something you would like to report or see in this document, please do not hesitate to open a new issue under the GitHub project for a working group.