# Heat Generation
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.
::: info Staking Recommended
Firechain isn't a PoW network, and PoW isn't always an option (i.e. there are limits on how much supplementary heat can be produced via PoW within a given time period, both at the account level and for the network as a whole). It's probably fine if you only intend to send one or two transactions here or there. However, it's recommended to stake rather than rely on PoW—especially if you plan to use the network on a regular basis.
:::
## Estimating Heat Generation
The table below shows the heat consumption of typical actions. You can use this to get a handle on how much heat capacity would be needed for the type of activity you expect to perform.
::: info Terminology
You'll see us refer to heat in two ways:
* *Scovilles* are the low-level raw units of heat generated.
* *Heat Units (H)* are equal to 21,000 Scovilles, which is the amount generated by a simple transfer.
:::
| Transaction Type | Scovilles | Heat Units (H) | Stake Needed |
|:------------:|:-----------:|:-----------:|:-----------:|
| Simple asset transfer (no data) | 21000 | 1 | 134 |
| Receive a transaction (no response) | 21000 | 1 | 134 |
| Deploy a contract | 31000 | 1.4762 | 267 |
| New validator registration | 168000 | 8 | 1067 |
| Change validator registration | 168000 | 8 | 1067 |
| Unregister validator | 126000 | 6 | 534 |
| Withdraw pending rewards | 147000 | 7 | 934 |
| New governance vote | 84000 | 4 | 534 |
| Retract governance vote | 52500 | 2.5 | 400 |
| Stake | 105000 | 5 | 667 |
| Stake (w/ callback) | 115500 | 5.5 | 800 |
| Unstake | 105000 | 5 | 667 |
| Unstake (w/ callback) | 115500 | 5.5 | 800 |
| Create a new token | 189000 | 9 | 1200 |
| Change token owner | 136500 | 6.5 | 934 |
| Change token type | 115500 | 5.5 | 800 |
| Mint tokens | 126000 | 6 | 800 |
| Burn tokens | 115500 | 5.5 | 800 |
| Query token (on-chain) | 31500 | 1.5 | 267 |
::: info Additional Heat Generation
* Any data in the transaction's comment field produces 56 Scovilles per character. For example, sending a transfer transaction with the data '0x6969' (two hexadecimal characters) will consume $H = 21000 + 56 * 2 = 21112$ Scovilles, which translates to $1.0053 H$.
* For contracts that require a specific global confirmation threshold, there is an additional heat consumption of $200 \times N_{confirmations}$ applied to each response transaction.
:::
## Calculating Heat Generation
Heat consumption can be calculated using the following formulas:
$$H_{PoW}=H_{max} \times (1- \frac{2}{1+e^{H_{recent} \times \xi d \times \rho d}})$$
$$H_{Stake}=H_{max} \times (1- \frac{2}{1+e^{H_{recent} \times \xi s \times \rho s}})$$
$$
H_{recent} =
\begin{cases}
1, & \text{for } H_{avg} \leq 1050000 \\
2-e^{8.260667775706495e-09 \times (H_{avg} - 1050000)}, & \text{for } 1050000 < H_{avg} \leq 2100000 \\
e^{1.6949794096275418e-10 \times (2100000-H_{avg})}-0.9, & \text{for } H_{avg} > 2100000 \\
\end{cases}
$$
* $H_{PoW}$: Heat capacity earned via Proof-of-Work (PoW). (Only valid for one transaction.)
* $H_{Stake}$: Heat capacity earned via staking. Recovers at a rate of 1/75 every global block.
* $H_{max}$: Heat capacity limit = $1,000,000 H$ (constant)
* $H_{recent}$: Heat capacity used in the current epoch
* $H_{avg}$: Global average heat generated in the current epoch
* $\xi d$: The difficulty of an accepted PoW solution
* $\rho d$: PoW solution weight = $6.259408129e-10$ (constant)
* $\xi s$: Account's current stake amount
* $\rho s$: Staking weight = $4.201037667e-24$ (constant)
**$H_{sec}$** is the amount of $H$ that an account can use in one second
$$H_{sec}=\frac{H_{Stake}}{21000}$$
**$H_{epoch}$** is amount of $H$ that an account can use in 1 epoch (75 global blocks)
$$H_{epoch}=H_{sec} \times 75$$
An account's heat capacity depends on $H_{sec}$ and $H_{recent}$. For example, if Alice's account earns $1.0 H_{sec}$ via staking and she hasn't sent any transactions in the last 74 blocks, she'd have $75 H$ of usable heat capacity.
However, the *usable* heat capacity also accounts for any added $H_{PoW}$ value. Extending the above example, if Alice provides a PoW solution that grants $2 H$, she'd have $77 H$ of usable heat capacity.
::: info Maximum Transaction Heat
For all transactions, a global maximum of $47.62 H$ applies, which means any transaction that would use more than $47.62 H$ will automatically fail.
:::
For reference, here's a mapping table for determining heat from $(\xi d \times \rho d)$ or $(\xi s \times \rho s)$:
| $(\xi d \times \rho d)$ or $(\xi s \times \rho s)$ | Scovilles | $H_{sec}$ | $H_{epoch}$ | Stake Required (w/o PoW) | PoW Required (w/o stake) |
|:------------:|:-----------:|:-----------:|:-----------:|:-----------:|:-----------:|
| 0.0 | 0 | 0 | 0 | 0 | 0 |
| $(0, 0.0005600000146345639)$ | 280 | 1/75 | 1 | 134 | 894654 |
| $(0.0005600000146345639, 0.0011200001170773874)$ | 560 | 2/75 | 2 | 267 | 1789307 |
| $(0.0011200001170773874, 0.0016800003951362111)$ | 840 | 3/75 | 3 | 400 | 2683961 |
| $(0.0016800003951362111, 0.002240000936619286)$ | 1120 | 4/75 | 4 | 534 | 3578615 |
| $(0.002240000936619286, 0.002800001829335484)$ | 1400 | 5/75 | 5 | 667 | 4473270 |
| $(0.0050400106687125265, 0.005600014634735637)$ | 2800 | 10/75 | 10 | 1334 | 8946557 |
| $(0.007840040157895736, 0.008400049392522762)$ | 4200 | 15/75 | 15 | 2000 | 13419879 |
| $(0.010640100380883094, 0.011200117079536328)$ | 5600 | 20/75 | 20 | 2667 | 17893253 |
| $(0.013440202315113498, 0.01400022867338966)$ | 7000 | 25/75 | 25 | 3333 | 22366698 |
| $(0.01624035693900638, 0.016800395152729273)$ | 8400 | 30/75 | 30 | 4000 | 26840230 |
| $(0.019040575232219203, 0.019600627497492765)$ | 9800 | 35/75 | 35 | 4666 | 31313868 |
| $(0.021840868175909127, 0.022400936689166498)$ | 11200 | 40/75 | 40 | 5333 | 35787628 |
| $(0.02464124675298827, 0.025201333711046034)$ | 12600 | 45/75 | 45 | 5999 | 40261529 |
| $(0.027441721948384734, 0.028001829548493135)$ | 14000 | 50/75 | 50 | 6666 | 44735587 |
| $(0.030242304749299606, 0.030802435189193574)$ | 15400 | 55/75 | 55 | 7333 | 49209821 |
| $(0.03304300614546563, 0.033603161623419094)$ | 16800 | 60/75 | 60 | 7999 | 53684248 |
| $(0.03584383712940819, 0.036404019844283514)$ | 18200 | 65/75 | 65 | 8666 | 58158886 |
| $(0.03864480869670122, 0.03920502084800278)$ | 19600 | 70/75 | 70 | 9333 | 62633751 |
| $(0.03920502084800278, 0.039765239150590236)$ | 19880 | 71/75 | 71 | 9466 | 63528753 |
| $(0.039765239150590236, 0.04032546369247644)$ | 20160 | 72/75 | 72 | 9599 | 64423765 |
| $(0.04032546369247644, 0.04088569456168163)$ | 20440 | 73/75 | 73 | 9733 | 65318787 |
| $(0.04088569456168163, 0.04144593184623087)$ | 20720 | 74/75 | 74 | 9866 | 66213820 |
| $(0, 0.042006175634155006)$ | 21000 | 1 | 75 | 10000 | 67108863 |
| $(0.042006175634155006, 0.08404944434245186)$ | 42000 | 2 | 150 | 20007 | 134276984 |
| $(0.08404944434245186, 0.1261670961035256)$ | 63000 | 3 | 225 | 30033 | 201563940 |
| $(0.1261670961035256, 0.16839681732546105)$ | 84000 | 4 | 300 | 40085 | 269029937 |
| $(0.16839681732546105, 0.2107768956769977)$ | 105000 | 5 | 375 | 50173 | 336736144 |
| $(0.382599842575369, 0.4263426931297194)$ | 210000 | 10 | 750 | 101486 | 681123015 |
| $(0.605878237567604, 0.6521731063496397)$ | 315000 | 15 | 1125 | 155241 | 1041908585 |
| $(0.8449180401302736, 0.8953840470548413)$ | 420000 | 20 | 1500 | 213135 | 1430461202 |
| $(1.1093075777848576, 1.1664348850068706)$ | 525000 | 25 | 1875 | 277654 | 1863490703 |
| $(1.4146605870070175, 1.4828322881625378)$ | 630000 | 30 | 2250 | 352969 | 2368965656 |
| $(1.7905932883378723, 1.8790328663947373)$ | 735000 | 35 | 2625 | 447279 | 3001933774 |
| $(2.3075451472522963, 2.4423470353692043)$ | 840000 | 40 | 3000 | 581368 | 3901881752 |
| $(2.4423470353692043, 2.594395323511559)$ | 861000 | 41 | 3075 | 617561 | 4144793358 |
| $(2.594395323511559, 2.7694056956796604)$ | 882000 | 42 | 3150 | 659220 | 4424389078 |
| $(2.7694056956796604, 2.976475888792767)$ | 903000 | 43 | 3225 | 708510 | 4755203412 |
| $(2.976475888792767, 3.2314282909393213)$ | 924000 | 44 | 3300 | 769198 | 5162514130 |
| $(3.2314282909393213, 3.5656840708200748)$ | 945000 | 45 | 3375 | 848763 | 5696519539 |
| $(3.5656840708200748, 4.057395776090949)$ | 966000 | 46 | 3450 | 965808 | 6482075769 |
| $(4.057395776090949, 5.029431885090279)$ | 987000 | 47 | 3525 | 1197189 | 8034995932 |
As shown in the table above, ignoring any PoW additions, a stake of 10,000 FIRE entitles the beneficiary to $1 H_{sec} \equiv 75 H_{epoch}$. The minimum stake (134 FIRE) provides just enough capacity to send one simple transfer per epoch (which is equivalent to $\frac{1}{74} H_{sec}$).
## Dynamic Heat Generation
In order to avoid extreme network congestion, Firechain implements a mechanism whereby the network's total heat usage over past 74 global blocks is used to estimate the current global load and dynamically adjust heat generation rates. As such, the amount of heat capacity required for any given transaction will scale with the network's load.
The following table outlines the required stake to achieve $1 H_{epoch}$ in various congestion scenarios.
| Global $H_{avg}$ | Congestion Factor | Stake |
|:------------:|:-----------:|:-----------:|
| 0-50 | 1 | 134 |
| 51 | 0.987079620361328125 | 135 |
| 52 | 0.97399139404296875 | 137 |
| 53 | 0.960735321044921875 | 139 |
| 54 | 0.947307586669921875 | 141 |
| 55 | 0.93370819091796875 | 143 |
| 60 | 0.8630218505859375 | 155 |
| 70 | 0.707286834716796875 | 189 |
| 80 | 0.53022003173828125 | 252 |
| 90 | 0.328899383544921875 | 407 |
| 100 | 0.0999999046325683594 | 1339 |
| 150 | 0.0869164466857910156 | 1541 |
| 200 | 0.0740036964416503906 | 1810 |
| 250 | 0.061260223388671875 | 2187 |
| 300 | 0.0486836433410644531 | 2752 |
| 350 | 0.0362710952758789062 | 3694 |
| 400 | 0.0240213871002197266 | 5578 |
| 410 | 0.0215908288955688477 | 6206 |
| 420 | 0.0191664695739746094 | 6991 |
| 430 | 0.0167486667633056641 | 8000 |
| 440 | 0.0143371224403381348 | 9346 |
| 450 | 0.0119318962097167969 | 11230 |
| 460 | 0.00953304767608642578 | 14056 |
| 470 | 0.0071404874324798584 | 18766 |
| 480 | 0.00475424528121948242 | 28185 |
| 490 | 0.00237426161766052246 | 56438 |
| 491 | 0.00213660299777984619 | 62716 |
| 492 | 0.00189901143312454224 | 70562 |
| 493 | 0.00166147947311401367 | 80650 |
| 494 | 0.00142402201890945435 | 94099 |
| 495 | 0.00118660926818847656 | 112926 |
| 496 | 0.000949271023273468018 | 141160 |
| 497 | 0.000711996108293533325 | 188203 |
| 498 | 0.000474780797958374023 | 282235 |
| 499 | 0.000237626954913139343 | 563908 |
## Getting Heat Capacity
### Staking (Recommended)
The recommended way to obtain heat capacity is through staking.
* The minimum staking amount is 134 FIRE. There's no maximum stake amount, but there is a $H_{max} = 1,000,000$.
* Capacity earned via staking can be credited to any account, which is to say you may stake for the benefit of anyone you chose. The beneficiary cannot be changed until the lock-up period expires. The staker always retains title to the staked tokens, regardless of the beneficiary.
* Staked FIRE is held by the built-in staking contract for the duration of the staking period.
* Staking can be revoked and funds retrieved by the staker after ~3 days (259.2k global blocks).
### One-Time PoW Solutions
If necessary, one can also get a transient heat capacity boost by solving a PoW challenge and including the solution when sending a transaction. For example, the difficulty required for a simple transfer (without any staking) is `0x3FFFFFF`.
#### Calculating PoW Challenges
1. Derive $target$ from $difficulty$:
$$target=\frac{2^{256}}{1+\frac{1}{difficulty}}$$
* $difficulty$ is the PoW challenge difficulty (padded to a length of 256 bits).
* $target$: is the 256-bit PoW target value.
For example, given a `difficulty = 0x3FFFFFF` then `target = 0xFFFFFFC000000000`.
2. Calculate $nonce$ based on transaction's data. In this process, a widely range of random numbers are assigned to $nonce$ until the following condition is satisfied:
$$blake2b(address+prevHash) + nonce < target$$
* $blake2b$: Hash function in Firechain
* $address$: User's account address
* $prevHash$: Hash of previous account block
## Frequently Asked Questions
### Can I stake and share my heat capacity with several accounts?
Yes. You can specify one beneficiary per staking transaction, so you would simply send one staking transaction per beneficiary address. It's currently not possible to re-assign an existing stake without first unstaking.
### Can I stake multiple times for the same beneficiary?
Yes. Doing so will produce several independent staking records, each with their own expiration. Heat capacity is calculated using the total of all beneficial stakes.
### Can multiple stakers provide capacity to the same beneficiary?
Yes. Heat capacity is calculated using the total of all beneficial stakes.
### Can I unstake before expiration?
No, it's not possible to retrieve your stake prior to the expiration of the lock-up period.
### Can heat capacity be used up?
Yes, but only transiently. It'll automatically restore at a rate of 1/75th per global block. In other words, if you exhausted your entire heat capacity right now, you'd get back to 100% in 75 global blocks. Heat is never permanent.
### Do I need heat capacity to receive a transaction?
Yes, receiving a transaction generates 21,000 Scovilles.
### What about transactions to or from a brand new account?
Because it's not possible for an account to stake before it exists, you'll either need to complete a PoW solution for one-time heat capacity, or have someone stake for your new account's benefit.
### Can I send transactions while the network is under heavy load?
Yes, but doing so will generate more heat than normal. Unless it's urgent, we recommend waiting for the load to go down before sending the transaction. Of course this is entirely discretionary, and you are free to send transactions so long as your heat capacity allows.