:::info This document explains the high-level concepts involved with running validators, including staking requirements, election criteria, and incentives. Definitions of Terms: Staking: Locking an amount of FIRE of the account for certain purpose. In this document, this is GV registration. One Round: A time period lasting exactly 75 seconds. One Cycle: Exactly 1,152 rounds, which is approximately one day. Staking Address: The candidate's registered and bonded address. Block Creation Address: The candidate's block signing address.

Overview Firechain uses a protocol-based voting mechanism for governance. There are two voting categories: global voting and delegated voting. The weighting of an account's vote is based on the amount of $FIRE held at the time of the vote, and weighting is applied to all elections for members of the global consensus group. Delegated voting is a more involved form of governance that's designed for use by smart contracts. For example, when a contract is deployed, it can designate a certain token whose holders can elect one or more specific nodes, or a specific consensus group, to process and validate the contract's responses. In addition to the "sealing" of account-level transactions through reference in global blocks, the global consensus group are responsible for performing breaking upgrades at the global level of the Firechain network. :::info Definitions: Super nodes are members of the global consensus group which are responsible for producing global blocks. Delegate nodes are part of a delegated consensus group and are tasked with producing blocks for delegated accounts (e.g. contracts and EOAs that opt-in).

Firechain.js is a JavaScript library for interacting with the Firechain network. It provides a set of simple APIs for things like sending transactions, querying the state of the blockchain, and deploying smart contracts, as well as a set of utility functions for encoding and decoding data. It also provides a set of networking modules for connecting to Firechain nodes. Firechain.js is available as an ES6 module and can be used in both Node.js and the browser. Installation Firechain.js is available as an npm package. We recommend using yarn to install it. yarn add @firechain/firechainjs yarn add @firechain/firechainjs-ws

The Firechain Network is a shared resource. It is a public good that is available to all users. In order to ensure that the network is available to all users, Firechain uses a dynamic resource sharing mechanism called Heat. It's a measure of the amount of demand that an account has placed on the network recently. Accounts generate heat when they interact with the network, and that heat dissipates over time automatically. The easiest way to think about Heat is as a form of congestion control which ensures that the network remains useful to the most inclusive group of users possible by way of limiting the load that any one account can put on the network. Understanding Heat Most blockchains require accounts to pay some sort of fee in order to transact over the network, primarily to prevent spam and misuse of the network's resources. Firechain does not use transaction fees. Instead, we developed the concept of heat which enables the network to operate without economic barriers that can be untenable for a large percentage of the population. To obtain heat capacity, you can: Stake FIRE (staking ~268 FIRE grants about 1 transaction per minute); or Produce a PoW solution to generate transient heat capacity when you need it.

Here's an example that produces content for a genesis.json file that can be used to spin up a new chain. It described a simple setup wherein 2 global and 2 are selected in each round and each is responsible for producing 3 consecutive blocks. The selection of GVs is based on the proportional distribution of delegate votes. This example has one "pinned" validator that's always picked, and the other is randomly selected from delegates whose weighted rank falls in the top 100. In order to be eligible, validators must register and stake at least 5000 FIRE for 1 Epoch (5,184,000 blocks ≈ 3 months) to become bonded. :::info This is a complete example, meaning you can use it to spin up a node. ::: const genesisConfig = { // Feature Flags

Firechain is an asynchronous decentralized application platform designed to power the open economy. It's built on top of the Firechain Async VM (AVM), a Turing-complete virtual machine capable of executing complex logic in a controlled, deterministic environment. Pyro is our async-first dApp development language that's designed to be intuitive and familiar to both Web2 and Web3 developers. Firechain is similar to other smart contract platforms like Ethereum, Cosmos, Solana, or Polkadot, but there are some key differences that set Firechain apart. NB: The Firechain network is currently in a pre-release stage, and it's not yet open to the public. The entire Firechain platform is intended to be open-source, however we're currently working hard to get it ready for launch and we're not quite ready to open it up to the world. We're excited to share our progress with the community in the coming months, and we'll be releasing more details about the Firechain platform as we get closer to launch. Platform Highlights The architecture of the Firechain network unlocks powerful new capabilities that most other blockchains simply can't offer, like no-fee transactions, instant finality, provably secure on-chain randomness, scheduled execution, on-chain event listeners, automation, prioritization, and so much more. The Async VM The Async VM (AVM) is our flagship innovation, and it's designed to power the next generation of decentralized applications. It's similar to Ethereum's virtual machine (EVM) in many ways, but it's not a fork of the EVM and it introduces unique concepts that require a slightly different way of thinking when building decentralized applications.

The Async VM (AVM) is Firechain's virtual machine and execution engine. It is a turing-complete VM with a rich set of instructions that can be used to build complex applications that run in a deterministic and trustless environment. The AVM natively supports asynchronous execution, which allows Firechain to execute smart contracts in parallel. In an effort to maintain compatibility with existing Web3 standards, most of the AVM's instructions are similar or identical to those of the Ethereum Virtual Machine (EVM). However, it's important to note that the AVM is not an EVM fork, and there are a number of differences in the way they operate that are important to understand. For example, the AVM handles CALLs asynchronously. This means that a CALL instruction will not block the execution of the current function. Instead, it will spawn an async request and return a message ID, and the execution of the current context will resume immediately. The spawned request might be executed in parallel to the current context, at some arbitrary later time, or perhaps not at all. In other words, it's not guaranteed when or if a remote execution request will return or have any observable effects. This is a powerful concept, and it's also a major difference between the AVM and the EVM which developers must consider when building on Firechain. The AVM, like other popular blockchain VMs, uses a call stack to control the context and flow of execution. Unlike most smart contract platforms, the AVM doesn't use a global stack. Instead, each account has its own execution stack, and each message is executed on its own stack. This means that the network can execute messages asynchronously, and each of those executions can further spawn reactive executions elsewhere in the system. It also allows contracts to schedule code to run at a specific time in the future, which opens the door to a wide range of use cases. It's easy to see how this model adds utility that the synchronous execution engines of other blockchains simply can't offer. The Power of Async The AVM's asynchronous execution engine is based on the actor model. In this model, each account is an actor that can send and receive messages to and from other actors in the system. Each account effectively has its own private state and its own message queue. When an account receives a message, it's placed into the account's queue until a validator executes the code associated with that message. The validator executes the code and then sends a response back to the sender. This response is placed into the sender's queue, and the sender can then process the response however it sees fit. The AVM's unique architecture allows for an inherently more efficient and scalable network. It also enables smart contract automation through on-chain event listeners and scheduled execution, as well as provably secure on-chain randomness.