From 657de6f4fbd319d373d89f05dc832e1dc1aeddfc Mon Sep 17 00:00:00 2001
From: mfahampshire <maxhampshire@pm.me>
Date: Wed, 25 Sep 2024 18:57:50 +0200
Subject: [PATCH] misc

---
 .../pages/network/architecture/mixnet.mdx     |  2 +-
 documentation/docs/pages/network/rewards.mdx  | 47 -------------------
 2 files changed, 1 insertion(+), 48 deletions(-)
 delete mode 100644 documentation/docs/pages/network/rewards.mdx

diff --git a/documentation/docs/pages/network/architecture/mixnet.mdx b/documentation/docs/pages/network/architecture/mixnet.mdx
index 3aa5bbe08d..7655db2e5a 100644
--- a/documentation/docs/pages/network/architecture/mixnet.mdx
+++ b/documentation/docs/pages/network/architecture/mixnet.mdx
@@ -4,7 +4,7 @@ The mixnet is made up of nodes running in several different roles:
 * **Gateways** act as message storage for clients which may go offline and come back online again, and (once zk-nyms are enabled) check for anonymous proof of access credentials. They represent the first and last hop Mixnet packets travel through when travelling between clients.
 * **Services** are applications that communicate with nym clients, listening and sending traffic to the mixnet. This is an umbrella term for a variety of different pieces of code, such as the Network Requester.
 
-> **Clients** are used to connect to and send messages through the Mixnet to other clients, utilising Gateways for ingress and egress. These are however on the 'user' side and not a Mixnet component per se.
+> **Clients** are used to connect to and send messages through the Mixnet to other clients, utilising Gateways for ingress and exit. These are however on the 'user' side and not a Mixnet component per se.
 
 ## Smoosh Status
 The various Mixnet components were originally completely separate binaries. They are in the process of being 'smooshed' together into a single `nym-node` binary which runs in different modes for ease of use, as well as to allow for a more developed and responsive Mixnet design, where the role of a node in a given time period is decided and changed automatically based on network conditions (more on this in the future).
diff --git a/documentation/docs/pages/network/rewards.mdx b/documentation/docs/pages/network/rewards.mdx
deleted file mode 100644
index 13c8d66fe2..0000000000
--- a/documentation/docs/pages/network/rewards.mdx
+++ /dev/null
@@ -1,47 +0,0 @@
-# Network Rewards
-
-Node operator and delegator rewards are determined according to the principles laid out in the section 6 of [Nym Whitepaper](https://nymtech.net/nym-whitepaper.pdf).
-
-Below is a TLDR of the variables and formulas involved in calculating these rewards per epoch. The initial reward pool contains 250 million NYM, leaving a circulating supply of 750 million NYM.
-
-TODO FIX
-
-|Symbol|Definition|
-|---|---|
-|<img src="https://render.githubusercontent.com/render/math?math=R"></img>|global share of rewards available, starts at 2% of the reward pool.
-|<img src="https://render.githubusercontent.com/render/math?math=R_{i}"></img>|node reward for mixnode `i`.
-|<img src="https://render.githubusercontent.com/render/math?math=\sigma_{i}"></img>|ratio of total node stake (node bond + all delegations) to the token circulating supply.
-|<img src="https://render.githubusercontent.com/render/math?math=\lambda_{i}"></img>|ratio of stake operator has pledged to their node to the token circulating supply.
-|<img src="https://render.githubusercontent.com/render/math?math=\omega_{i}"></img>|fraction of total effort undertaken by node `i`.
-|<img src="https://render.githubusercontent.com/render/math?math=k"></img>|number of nodes stakeholders are incentivised to create, set by the validators, a matter of governance. Currently determined by the reward set size.
-|<img src="https://render.githubusercontent.com/render/math?math=\alpha"></img>|Sybil attack resistance parameter - the higher this parameter is set the stronger the reduction in competitivness gets for a Sybil attacker.
-|<img src="https://render.githubusercontent.com/render/math?math=PM_{i}"></img>|declared profit margin of operator `i`.
-|<img src="https://render.githubusercontent.com/render/math?math=PF_{i}"></img>|uptime of node `i`, scaled to 0 - 1, for the rewarding epoch
-|<img src="https://render.githubusercontent.com/render/math?math=PP_{i}"></img>|cost of operating node `i` for the duration of the rewarding eopoch.
-
-Node reward for node `i` is determined as:
-
-<img src="https://render.githubusercontent.com/render/math?math=R_{i}=PF_{i} \cdot R \cdot (\sigma^'_{i} \cdot \omega_{i} \cdot k %2b \alpha \cdot \lambda^'_{i} \cdot \sigma^'_{i} \cdot k)/(1 %2b \alpha)"></img>
-
-
-where:
-
-<img src="https://render.githubusercontent.com/render/math?math=\sigma^'_{i} = min\{\sigma_{i}, 1/k\}"></img>
-
-
-and
-
-<img src="https://render.githubusercontent.com/render/math?math=\lambda^'_{i} = min\{\lambda_{i}, 1/k\}"></img>
-
-
-Operator of node `i` is credited with the following amount:
-
-<img src="https://render.githubusercontent.com/render/math?math=min\{PP_{i},R_{i}\} %2b max\{0, (PM_{i} %2b (1 - PM_{i}) \cdot \lambda_{i}/\delta_{i}) \cdot (R_{i} - PP_{i})\}"></img>
-
-
-Delegate with stake `s` recieves:
-
-<img src="https://render.githubusercontent.com/render/math?math=max\{0, (1-PM_{i}) \cdot (s^'/\sigma_{i}) \cdot (R_{i} - PP_{i})\}"></img>
-
-
-where `s'` is stake `s` scaled over total token circulating supply.