diff --git a/content/algorithms/expected_consensus/_index.md b/content/algorithms/expected_consensus/_index.md
index 672bd7835..78997d59f 100644
--- a/content/algorithms/expected_consensus/_index.md
+++ b/content/algorithms/expected_consensus/_index.md
@@ -11,7 +11,7 @@ dashboardTests: 0
 
 ## Algorithm
 
-Expected Consensus (EC) is a probabilistic Byzantine fault-tolerant consensus protocol. At a high level, it operates by running a leader election every epoch in which, on expectation, a set number of participants may be eligible to submit a block. EC guarantees that these winners will be anonymous until they reveal themselves by submitting a proof that they have been elected, the `ElectionProof`. Each winning miner can submit one such proof per round and will be rewarded proportionally to its power. From this point on, each wining miner also creates a proof of storage (aka Winning PoSt). Each proof can be derived from a [properly formatted beacon entry](randomness), as described below.
+Expected Consensus (EC) is a probabilistic Byzantine fault-tolerant consensus protocol. At a high level, it operates by running a leader election every epoch in which, on expectation, a set number of participants may be eligible to submit a block. EC guarantees that these winners will be anonymous until they reveal themselves by submitting a proof that they have been elected, the `ElectionProof`. Each winning miner can submit one such proof per round and will be rewarded proportionally to its power. From this point on, each winning miner also creates a proof of storage (aka Winning PoSt). Each proof can be derived from a [properly formatted beacon entry](randomness), as described below.
 
 All valid blocks submitted in a given round form a `Tipset`. Every block in a Tipset adds weight to its chain. The 'best' chain is the one with the highest weight, which is to say that the fork choice rule is to choose the heaviest known chain. For more details on how to select the heaviest chain, see [Chain Selection](expected_consensus#chain-selection). While on expectation at least one block will be generated at every round, in cases where no one finds a block in a given round, a miner can simply run leader election again for the next epoch with the appropriate random seed, thereby ensuring liveness in the protocol.
 
diff --git a/content/appendix/audit_reports.md b/content/appendix/audit_reports.md
index c03051c9e..bf81591b1 100644
--- a/content/appendix/audit_reports.md
+++ b/content/appendix/audit_reports.md
@@ -55,6 +55,14 @@ This audit covers the implementation of Filecoin's builtin Actors, focusing on t
 
 ## Proofs
 
+### `2021-05-31` SnarkPack audit
+
+An audit was conducted on the cryptographic part of [SnarkPack](https://eprint.iacr.org/2021/529.pdf), that is used in the [FIP0009](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0009.md):
+
+- [Report](https://hackmd.io/@LIRa8YONSwKxiRz3cficng/B105no8w_) from Matteo Campanelli, a well known cryptography [researcher](https://www.binarywhales.com/)
+
+One major issue was found in the report by Campanelli where the challenges of each prove commits were not tied to the aggregated proof; this could have led up to malicious miner forge valid aggregated proofs without the individual prove commits. The rest of the issues were of medium to informal severity.
+
 ### `2020-10-20` Filecoin Bellman and BLS Signatures
 
 - Report: [**Filecoin Bellman/BLS Signatures Cryptography Review**](https://research.nccgroup.com/wp-content/uploads/2020/10/NCC_Group_ProtocolLabs_PRLB007_Report_2020-10-20_v1.0.pdf)
diff --git a/content/glossary/_index.md b/content/glossary/_index.md
index 5b622c9a7..ab7e7ef2f 100644
--- a/content/glossary/_index.md
+++ b/content/glossary/_index.md
@@ -377,7 +377,7 @@ Every mined block has a computed `weight`, also called its `WinCount`. Together,
 
 [_Window Proof-of-Spacetime_ (WindowPoSt)](post#windowpost) is the mechanism by which the commitments made by [storage miners](glossary#storage-miner-actor) are audited. It sees each 24-hour period broken down into a series of windows. Correspondingly, each storage miner's set of pledged [sectors](glossary#sector) is partitioned into subsets, one subset for each window. Within a given window, each storage miner must submit a [Proof-of-Spacetime](glossary#proof-of-spacetime-post) for each sector in their respective subset. This requires ready access to each of the challenged sectors, and will result in a [zk-SNARK-compressed](glossary#zksnark) proof published to the Filecoin [blockchain](glossary#blockchain) as a [message](glossary#message) in a [block](glossary#block). In this way, every sector of [pledged storage](glossary#pledged-storage) is audited at least once in any 24-hour period, and a permanent, verifiable, and public record attesting to each storage miner's continued commitment is kept.
 
-The Filecoin network expects constant availability of stored data. Failing to submit WindowPoSt for a sector will result in a [fault](glossary#fault), and the storage miner supplying the sector will be [slashed](glossary#slash).
+The Filecoin network expects constant availability of stored data. Failing to submit WindowPoSt for a sector will result in a [fault](glossary#fault), and the storage miner supplying the sector will be [slashed](glossary#slashing).
 
 ## Winning Proof-of-Spacetime (WinningPoSt)
 
diff --git a/content/libraries/drand/_index.md b/content/libraries/drand/_index.md
index 0ff7a285d..2f3b6f33d 100644
--- a/content/libraries/drand/_index.md
+++ b/content/libraries/drand/_index.md
@@ -29,6 +29,7 @@ By polling the appropriate endpoint (see below for specifics on the drand networ
 ```json
 {
   "round": 367,
+  "randomness": "3439d92d58e47d342131d446a3abe264396dd264717897af30525c98408c834f",
   "signature": "b62dd642e939191af1f9e15bef0f0b0e9562a5f570a12a231864afe468377e2a6424a92ccfc34ef1471cbd58c37c6b020cf75ce9446d2aa1252a090250b2b1441f8a2a0d22208dcc09332eaa0143c4a508be13de63978dbed273e3b9813130d5",
   "previous_signature": "afc545efb57f591dbdf833c339b3369f569566a93e49578db46b6586299422483b7a2d595814046e2847494b401650a0050981e716e531b6f4b620909c2bf1476fd82cf788a110becbc77e55746a7cccd47fb171e8ae2eea2a22fcc6a512486d"
 }
@@ -36,6 +37,7 @@ By polling the appropriate endpoint (see below for specifics on the drand networ
 
 Specifically, we have:
 
+- `Randomness` -- SHA256 hash of the signature
 - `Signature` -- the threshold BLS signature on the previous signature value `Previous` and the current round number `round`.
 - `PreviousSignature` -- the threshold BLS signature from the previous drand round.
 - `Round` -- the index of Randomness in the sequence of all random values produced by this drand network.
@@ -69,7 +71,7 @@ endpoint.
 Thereafter, the Filecoin client can call drand's endpoints:
 
 - `/public/latest` to get the latest randomness value produced by the beacon
-- `/public/<round>` to get the randoomness value produced by the beacon at a given round
+- `/public/<round>` to get the randomness value produced by the beacon at a given round
 
 ## Using drand in Filecoin
 
diff --git a/content/systems/filecoin_mining/sector/adding_storage.md b/content/systems/filecoin_mining/sector/adding_storage.md
index 3fc1b322e..25c70be68 100644
--- a/content/systems/filecoin_mining/sector/adding_storage.md
+++ b/content/systems/filecoin_mining/sector/adding_storage.md
@@ -32,7 +32,7 @@ To facilitate this, there are _two types_ of Sectors that may be sealed and Prov
 - **Regular Sector**: A Sector that contains Client data
 - **Committed Capacity (CC) Sector**: A Sector with no data (all zeroes)
 
-Miners are free to coose which types of Sectors to store. CC sectors, in particular, allow Miners to immediately make use of existing disk space: earning storage power and a higher chance at producing a block. Miners can decide if they should upgrade their CC sectors to take client deals or continue proving CC sectors. Currently, CC sectors store randomness by default in client implementation, but this does not preclude miners from storing any type of useful data that increase their private utility in CC sectors (as long as it is legal). The protocol expects that new use-cases and diversity will emerge out of such behaviour.
+Miners are free to choose which types of Sectors to store. CC sectors, in particular, allow Miners to immediately make use of existing disk space: earning storage power and a higher chance at producing a block. Miners can decide if they should upgrade their CC sectors to take client deals or continue proving CC sectors. Currently, CC sectors store randomness by default in client implementation, but this does not preclude miners from storing any type of useful data that increase their private utility in CC sectors (as long as it is legal). The protocol expects that new use-cases and diversity will emerge out of such behaviour.
 
 To incentivize Miners to hoard storage space and dedicate it to Filecoin, CC Sectors have a unique capability: **they can be "upgraded" to Regular Sectors** (also called "replacing a CC Sector").
 
diff --git a/content/systems/filecoin_mining/sector/lifecycle.md b/content/systems/filecoin_mining/sector/lifecycle.md
index 2f056bfcb..f1e346019 100644
--- a/content/systems/filecoin_mining/sector/lifecycle.md
+++ b/content/systems/filecoin_mining/sector/lifecycle.md
@@ -15,7 +15,7 @@ In particular, as sectors of shorter lifetime are added, the networkʼs capacity
 
 It is reasonable to assume that miners enter the network by adding Committed Capacity sectors, that is, sectors that do not contain user data. Once miners agree storage deals with clients, they upgrade their sectors to Regular Sectors. Alternatively, if they find Verified Clients and agree a storage deal with them, they upgrade their sector accordingly. Depending on whether or not a sector includes a (verified) deal, the miner acquires the corresponding storage power in the network.
 
-All sectors are expected to remain live until the end of their sector lifetime and early dropping of sectors will result in slashing. This is done to provide clients a certain level of guarantee on the reliability of their hosted data. Sector termination can comes with a corresponding _termination fee_.
+All sectors are expected to remain live until the end of their sector lifetime and early dropping of sectors will result in slashing. This is done to provide clients a certain level of guarantee on the reliability of their hosted data. Sector termination comes with a corresponding _termination fee_.
 
 As with every system it is expected that sectors will present faults. Although this might degrade the quality offered by the network, the reaction of the miner to the fault drives system decisions on whether or not the miner should be penalized. A miner can recover the faulty sector, let the system terminate the sector automatically after 42 days of faults, or proactively terminate the sector immediately in the case of unrecoverable data loss. In case of a faulty sector, a small penalty fee approximately equal to the block reward that the sector would win per day is applied. The fee is calculated per day of the sector being unavailable to the network, i.e. until the sector is recovered or terminated.
 
diff --git a/content/systems/filecoin_token/minting_model/_index.md b/content/systems/filecoin_token/minting_model/_index.md
index 60155f518..34f7fea22 100644
--- a/content/systems/filecoin_token/minting_model/_index.md
+++ b/content/systems/filecoin_token/minting_model/_index.md
@@ -18,7 +18,7 @@ To encourage consistent storage onboarding and investment in long-term storage,
 
 Specifically, a hybrid exponential minting mechanism is introduced with a proportion of the reward coming from simple exponential decay, “Simple Minting” and the other proportion from network baseline, “Baseline Minting”. The total reward per epoch will be the sum of the two rewards. Mining Filecoin should be even more profitable with this mechanism. Simple minting allocation disproportionately rewards early miners and provides counter pressure to shocks. Baseline minting allocation mints more tokens when more value for the network has been created. More tokens are minted to facilitate greater trade when the network can unlock a greater potential. This should lead to increased creation of value for the network and lower risk of minting filecoin too quickly.
 
-The protocol allocates 30% of Storage Mining Allocation in Simple Minting and the remaining 70% in Baseline Minting. 30% of Simple Minting can provide counter forces in the event of shocks. Baseline capacity can start from a smaller percentage of worldʼs storage today, grow at a rapid rate, and catch up to a higher but still reasonable percentage of worldʼs storage in the future. As such, the network baseline will start from 1EiB (which is less than 0.01% of the worldʼs storage today) and grow at an annual rate of 200% (higher than the usual world storage annual growth rate at 40%). The community can come together to slow down the rate of growth when the network is providing 1-10% of the worldʼs storage.
+The protocol allocates 30% of Storage Mining Allocation in Simple Minting and the remaining 70% in Baseline Minting. 30% of Simple Minting can provide counter forces in the event of shocks. Baseline capacity can start from a smaller percentage of worldʼs storage today, grow at a rapid rate, and catch up to a higher but still reasonable percentage of worldʼs storage in the future. The network baseline will start from **2.5EiB**, or **2.88888888EB**, (which is less than 0.01% of the worldʼs storage today) and grow at an annual rate of 100% (higher than the usual world storage annual growth rate at 40%). The community can come together to slow down the rate of growth when the network is providing 1-10% of the worldʼs storage.
 
 There are many features that will make passing the baseline more efficient and economical and unleash a greater share of baseline minting. The community can come together to collectively achieve these goals:
 
diff --git a/package.json b/package.json
index 0cc535e5a..093b76ee5 100644
--- a/package.json
+++ b/package.json
@@ -35,7 +35,7 @@
     "globby": "^11.0.1",
     "graphviz-cli": "^2.0.0",
     "hugo-extended": "^0.113.0",
-    "husky": ">=4",
+    "husky": "^4.3.8",
     "jsdom": "^22.1.0",
     "lint-staged": ">=10",
     "np": "^6.5.0",