Update Tokenomics images and other small fixes (#129)

Solution
========

- Added tokenomics diagrams
- Removed unused fonts
- Upgraded mdbook
- Fix links
- Fix grammar
- fix scroll issue

### Testing

- Pull
- npm i
- Install new mdbook (see readme changes)
- mdbook serve


Screenshots (optional):
-----------------------

![image](https://github.com/user-attachments/assets/72740ddc-8bd7-43d0-abcf-71dc4ad2caaa)


![image](https://github.com/user-attachments/assets/e1b2941f-d432-44dc-8ee8-53596e1a74fe)

Author: wilwade

.github/workflows/common/set-up-mdbook/action.yaml

@@ -11,7 +11,7 @@ runs:
       uses: jontze/action-mdbook@6c0be56d14c4bf16861b00af61f50ff7400ce502
       with:
         token: ${{ inputs.token }}
-        mdbook-version: "0.4.49" # Use a semver compatible string
+        mdbook-version: "0.4.51" # Use a semver compatible string
 
     - name: Show mdbook version
       shell: bash

README.md

@@ -13,7 +13,7 @@ or [Frequency on GitHub](https://github.com/frequency-chain/frequency)
 To build the generator locally, install [mdBook](https://github.com/rust-lang/mdBook.git).
 
 ```bash
-cargo install mdbook@0.4.49
+cargo install mdbook@0.4.51
 npm install
 ```
 

css/overrides.css

@@ -135,7 +135,7 @@ body#sidebar {
 #sidebar .sidebar-scrollbox {
   display: block;
   position: sticky;
-  top: 80px;
+  top: calc(var(--header-height) - 5px);
   box-sizing: padding-box;
   padding: 0;
   max-height: 100vh;
@@ -309,6 +309,7 @@ mark {
 
 h1:target::before {
   display: none;
+  margin-inline-start: 0;
 }
 
 h2:target::before,
@@ -318,6 +319,7 @@ h3:target::before {
   width: 50px;
   position: relative;
   color: var(--headers);
+  margin-inline-start: 0;
 }
 
 h4:target::before,
@@ -328,6 +330,7 @@ h6:target::before {
   width: 40px;
   position: relative;
   color: var(--headers);
+  margin-inline-start: 0;
 }
 
 /* Override some colors */
@@ -339,6 +342,33 @@ h6:target::before {
   color: var(--headers);
 }
 
+#mdbook-help-popup kbd {
+  color: var(--bg);
+  background-color: var(--fg);
+}
+
+.warning {
+  padding-left: 30px;
+}
+.warning:before {
+  margin-inline-start: calc(-1.5rem - 30px);
+}
+
+/* Table settings */
+
+table thead {
+  background: var(--table-header-bg);
+  color: var(--table-header-fg);
+}
+table thead th {
+  border: 1px var(--table-header-fg) solid;
+}
+/* Alternate background colors for rows */
+table tbody tr:nth-child(2n) {
+  background: var(--table-alternate-bg);
+  color: var(--table-alternate-fg);
+}
+
 /* Replace Font-Awesome */
 
 .fa.fa-github {

pages/Governance/index.md

@@ -1,6 +1,6 @@
 # Governance
 
-Frequency Governance currently uses [Polkadot Governance V1](https://wiki.polkadot.network/learn/archive/learn-governance/): a tricameral governance structure which includes coordinated governance by three institutions: the [Frequency Council](https://dotapps-io.ipns.dweb.link?rpc=wss%3A%2F%2F1.rpc.frequency.xyz#/council), analogous to the Council in Polkadot Governance V1, the [Technical Committee](https://dotapps-io.ipns.dweb.link?rpc=wss%3A%2F%2F1.rpc.frequency.xyz#/techcomm), analogous to the Technical Committee in Polkadot Governance V1, and token holder voting, analogous to the Public in Polkadot Governance V1.
+Frequency Governance currently uses [Polkadot Governance V1](https://github.com/w3f/polkadot-wiki/blob/52440693c9db5d300fd843b16c95bd6edd0fe6fe/docs/learn/archive/learn-governance.md): a tricameral governance structure which includes coordinated governance by three institutions: the [Frequency Council](https://dotapps-io.ipns.dweb.link?rpc=wss%3A%2F%2F1.rpc.frequency.xyz#/council), analogous to the Council in Polkadot Governance V1, the [Technical Committee](https://dotapps-io.ipns.dweb.link?rpc=wss%3A%2F%2F1.rpc.frequency.xyz#/techcomm), analogous to the Technical Committee in Polkadot Governance V1, and token holder voting, analogous to the Public in Polkadot Governance V1.
 
 ## Governance Parameters
 

pages/Tokenomics/CapacityStaking.md

@@ -13,7 +13,7 @@ The second goal is minimizing spam in a system designed to minimize Message publ
 As the cost of Message publishing decreases, the viability of spam Messages increases proportionally.
 The design of Capacity attempts to balance these two goals while minimizing excessive churn of the native token itself.
 
-<!-- TODO: Add diagram -->
+{{#svg-embed pages/images/CapacitySimple.svg Capacity Staking Diagram}}
 
 While all transaction fees on Frequency can be paid for with FRQCY, certain types of transaction fees can instead use an equivalent amount of Capacity, which strikes a balance between Message publishing and Stateful Storage cost on one hand, and spam prevention on the other, using three core mechanisms: staking, renewal, and unstaking.
 

pages/Tokenomics/CollatorRewards.md

@@ -6,7 +6,7 @@ However, block formation is still a Frequency responsibility that must be perfor
 [Public Collators](../Glossary.md#public-collator) must stake to the network to participate.
 All Collators participating in block formation activities will eventually receive token rewards, though the details of this mechanism will be finalized as part of the process of launching Public Collators.
 
-<!-- TODO: DIAGRAM -->
+{{#svg-embed pages/images/CollatorRewards.svg Collator Rewards Diagram}}
 
 Collators are analogous to validators in other proof of stake networks, but the work done by Collators is significantly lower, requiring less computational overhead and lower participation levels, given that consensus and finality occur at the Relay Chain level.
 Public Collators are currently a roadmap item, and Frequency currently uses [Invulnerable Collators](../Glossary.md#invulnerable-collator) that do not receive rewards for block formation.

pages/Tokenomics/InflationLiquidity.md

@@ -30,7 +30,7 @@ However, governance deposits are not anticipated to generate significant reducti
 Decreases in circulating supply are triggered primarily by increased staking activity.
 Both Capacity Staking and Provider Boosting lower overall token circulation levels as the number of staked tokens increase.
 Given the utility that these staking mechanisms provide, relatively high global stake rates are assumed in both early and later stages of the network.
-Staking levels don't decrease Providers’ ability to pay transactions fees for certain transaction types, however, given that both types of staking generate Capacity.
+Staking levels don't decrease Providers’ ability to pay transaction fees for certain transaction types, however, given that both types of staking generate Capacity.
 Generally, staking models require derivatives like "liquid staking" or they risk decreasing network transactions due to a smaller circulating supply of tokens available to pay transaction fees, which can reduce the value of the network.
 Frequency is less susceptible to that correlation, since Capacity generated from staking can actually be spent on transaction fees.
 This means that a lower circulating supply of FRQCY does not necessarily result in a lower transaction volume on chain due to Capacity-related transactions.

pages/Tokenomics/ProviderBoosting.md

@@ -4,7 +4,7 @@ Frequency incorporates a second form of staking called Provider Boosting.
 While Capacity Staking solely produces Capacity and is designed to help Providers maximize economic utility for publishing Messages and managing Stateful Storage, Provider Boosting gives users a mechanism to provide support for, or withdraw support from, Providers by staking FRQCY.
 Provider Boosting also gives individual users a mechanism to receive FRQCY rewards directly and benefit from the value accrual potential of the broader cryptoeconomic system.
 
-<!-- TODO: Insert diagram here -->
+{{#svg-embed pages/images/ProviderBoosting.svg Provider Boosting Diagram}}
 
 Like Capacity Staking, Provider Boosting also generates Capacity and therefore requires a Provider to be designated as part of the staking process.
 In this scenario, a different ratio of FRQCY to Capacity (the Provider Boosting Ratio) is used, which is always less token-efficient than the Capacity Staking Ratio in order to generate an equivalent amount of Capacity.
@@ -15,7 +15,7 @@ The reward is distributed at the end of each Reward Epoch, a number of blocks se
 
 Users must maintain their full stake throughout the entirety of the Reward Epoch in order to qualify for a reward.
 Each Reward Epoch has a fixed number of tokens that can be minted to reward Provider Boosting participants, and those rewards are paid based on the ratio of the user's Provider Boosting stake to all user Provider Boosting stakes across all Providers.
-Token for rewards are not minted during, or at the end of, the Reward Epoch.
+Tokens for rewards are not minted during, or at the end of, the Reward Epoch.
 Instead, tokens are minted at the time they are claimed by the Token Account holder, sometime after the end of the applicable Reward Epoch.
 However, all rewards are capped at a maximum Annual Rewards Rate set by governance.
 Given that the reward is paid via new token minting, the reward for Provider Boosting contributes to FRQCY inflation.

pages/Tokenomics/index.md

@@ -1,7 +1,7 @@
 # Tokenomics
 
 Frequency's economic model has been designed to optimize for the scalability concerns associated with social networking activities at population scale, broadly defined as any interaction between two or more participants in the global network.
-The design anticipates a mix of data focused transactions centered around writes, updates, and reads applied to a highly scaled corpus of data.
+The design anticipates a mix of data-focused transactions centered around writes, updates, and reads applied to a highly scaled corpus of data.
 Key objectives of the design are to minimize price volatility and facilitate value capture over the long term.
 
 Like most blockchains, Frequency enables transaction fees to be paid in its native token: Mainnet utilizes a utility token called FRQCY, while on Testnet, the token is denoted as XRQCY.