Frequently Asked Questions

Flow is a proof of stake blockchain designed to be the foundation of Web3 and the open metaverse, supporting consumer-scale decentralized applications, NFTs, DeFi, DAOs, PFP projects, and more. Powered by Cadence, an original programming language built specifically for digital assets, Flow empowers developers to innovate and push the limits that will bring the next billion to Web3. Created by a team that has consistently delivered industry-leading consumer-scale experiences including CryptoKitties, NBA Top Shot, and NFL ALL DAY, Flow is an open, decentralized platform with a thriving ecosystem of creators from top brands, development studios, venture-backed startups, crypto leaders, and more.

FLOW is the native currency of the Flow network. It is the exclusive token for staking, delegating, paying transaction fees, and paying storage fees. It is also the primary token used for buying, selling, and trading assets and experiences on Flow.

Yes, as of October 2021, less than 1/3 of consensus nodes, the nodes responsible for the security of the network, are run by any single entity. Cadence, Flow's programming language, is still in beta but will be available for permissionless deployment in the summer of 2022.

Yes – the native token for the Flow network is FLOW. All decentralized blockchains use cryptographic tokens (cryptocurrencies) to ensure the security of the system.

You can start building on Flow immediately! Visit docs.onflow.org to get going.

Composability refers to developers building on top of shared standards - for example: contract standards like those that define fungible and non-fungible tokens or integration standards like the Flow Client Library (FCL) - or shared resources like an existing user base (i.e. community), public data, or existing platforms.

This opportunity for integration allows developers to jump start their own applications and ecosystems by building on existing infrastructure without platform risk (i.e. the risk that the service built on could be turned off). This is something made uniquely possible by standards and resources existing on decentralised blockchains like Flow.

Jesse Walden of a16z says ""A platform is composable if its existing resources can be used as building blocks and programmed into higher order applications. Composability is important because it allows developers to do more with less, which in turn, can lead to more rapid and compounding innovation.” – Jesse Walden, 4 eras of blockchain computing

Flow is unique in that it addresses the scalability trilemma - a problem that forces trade-offs between scale, security and decentralisation which public blockchains face - by dividing the security and performance work over different groups of nodes which are each specialised for their respective tasks. This unique multi-node architecture allows Flow to scale performantly to service mainstream adoption without compromising the security or long term decentralisation of the network. This multi-node architecture also allows Flow to provide full ACID guarantees which unlocks rich interactions between smart contracts ("composability") and creates strong network effects for apps built on Flow without the complexity of sharding (other chains answer to managing complex state).

The Flow Architecture defines an Access role specifically to provide cryptographic proofs of transaction outcomes. Furthermore, Access Nodes are also designed to answer general state queries and supply proofs of correctness. Client software works with Access Nodes to provide users with a view of the network that is accurate and secure, without requiring those clients to keep up with the torrent of traffic flowing through the entire network.

The number of Access Nodes in the network has no fixed limit, which will support a practically unbounded number of light clients fetching full state proofs.

Specialized Proofs of Confidential Knowledge (SPoCKs) are a new cryptographic technique developed by the Flow team, formally defined in a technical paper. SPoCKs allow any number of provers to demonstrate to a third-party observer that they each have access to the same confidential knowledge. These proofs are non-interactive and don’t leak information about the confidential knowledge itself. Each prover’s SPoCK is specialized to them, and can’t be copied or forged by any other prover.

Flow uses SPoCKs to address the Verifier’s Dilemma by requiring Execution and Verification Nodes to “show their work”. In order to get paid, these nodes need to provide a SPoCK showing access to confidential knowledge that can only be obtained by executing all of the transactions assigned to them.

When porting dapps from Ethereum to Flow, the following should be considered:

1. ACID properties can be assumed, just like on Ethereum. Thus, all dapps can assume a single shared state space, and don't need to be rearchitected to support a sharded environment or asynchronous function calls.

2. The programming language for Flow is Cadence. It is not compatible with EVM. Thus, smart contract logic needs to be re-implemented. The effort for the implementation largely depends upon the context and complexity of the application. Porting will be simple for NFT-based projects primarily off-the-shelf use cases: transferring, minting, selling on secondary market places, royalties, etc. It will be much more involved if Ethereum-specific ecosystem tools and services were utilized. For instance, the stablecoins compatible with the Flow ecosystem might be different to the ones dapp builders used on Ethereum. Right now, Flow supports FUSD, tUSDT, and USDC.

3. The integration of blockchain interactions into web applications can be done with FCL, a JS library. While architecturally different, it accomplishes similar goals as web3.js. Web applications will need to be updated to support FCL (handling transactions, handling authentication, and handling queries to Flow).

4. The token standards for Flow are implemented differently to account for the resource-oriented programming model represented in Cadence.

5. The wallets compatible with the Flow ecosystem are not the same wallets users and dapp builders are familiar with. Their users accounts would need to be re-created.For a comparison of building blocks for common NFT use cases, please check out the Flow documentation.

The workhorses of the Flow architecture are the Execution Nodes. You shouldn’t simply think of Execution Nodes as fast computers; each of them is likely to be an entire cluster of high-end server hardware colocated in a professional data center.

Execution Nodes are super fast and have very high staking requirements, but are only ever entrusted with executing the deterministic block transition function. All of the work they do is verified and confirmed by the network of Consensus and Verification Nodes.

Collectively, the Verification Nodes will confirm every part of the block computation many times over, but each individual Verification Node will only do a fraction of the work. For example, if there are 1000 Verification Nodes, each Verification Node would only need to check 4% of the total block for the entire block has been inspected 40 times over. The Flow Technical Papers provide the full details and security analysis of this approach.

The Scalability Trilemma is an important conjecture made by Vitalik Buterin that is not formally proven, but is almost certainly correct for homogenous blockchain designs. If every node in the network has the same role, you have to compromise on at least one of those dimensions.

Flow doesn’t “break” or disprove the Trilemma, it dodges around it. The trick is noting that, if we let different nodes participate in different roles, we can choose the right trade-offs for each part of the system.

Flow maximizes security and decentralization for the Consensus Nodes, the part of the system most vulnerable to Byzantine attacks. This limits their scalability, of course, but that isn’t actually a problem because we don’t ask the Consensus Nodes to do anything computationally expensive.

On the other hand, we crank up the scalability for Execution Nodes to dramatically increase computation throughput. This compromises the security and decentralization of those nodes, which we address by ensuring that every step of every transaction is confirmed by the high security and decentralised Verification Nodes.

For each node type, the Trilemma holds as expected, but the overall effect is a system where the weaknesses of one part of the system are more than offset by the strengths of the other parts.

The Flovatar team has put together a helpful guide for getting Flow.

You can find a list of exchanges FLOW is available on here.

You can store them in a wallet. You can find wallets supporting FLOW here: https://www.flowverse.co/projects

Flow is a multi purpose blockchain that supports everything  the world of web3 has to offer including: fungible tokens (FTs), non-fungible tokens (NFTs), decentralised autonomous organisations (DAOs), profile pictures (PFPs), and is home to Cadence - a fully featured programming language for building anything you can imagine.

CryptoKitties rendered Etheruem unusable in December 2017. Read more here.

No, currently ledgers can't be used for NFTs. For now, the ledger team only allows an approved set of transactions with ledger devices. That said, NFTs may be allowed in the future.

Cadence is Turing complete, so anything can be built with it, including fractional NFTS.

The Flow Client Library (FCL) JS is a package used to interact with user wallets and the Flow blockchain. When using FCL for authentication, dapps are able to support all FCL-compatible wallets on Flow and their users without any custom integrations or changes needed to the dapp code.

It was created to make developing applications that connect to the Flow blockchain easy and secure. It defines a standardized set of communication patterns between wallets, applications, and users that is used to perform a wide variety of actions for your dapp. FCL also offers a full featured SDK and utilities to interact with the Flow blockchain.