diff --git a/arbitrum-docs/how-arbitrum-works/08-anytrust-protocol.mdx b/arbitrum-docs/how-arbitrum-works/08-anytrust-protocol.mdx
index 781c4bc02..24799e8f9 100644
--- a/arbitrum-docs/how-arbitrum-works/08-anytrust-protocol.mdx
+++ b/arbitrum-docs/how-arbitrum-works/08-anytrust-protocol.mdx
@@ -11,13 +11,13 @@ AnyTrust is a variant of <a data-quicklook-from="arbitrum">Arbitrum</a> Nitro te
 
 The Arbitrum protocol requires that all Arbitrum nodes, including validators (nodes that verify correctness of the chain and are prepared to stake on correct results), have access to the data of every L2 <a data-quicklook-from="transaction">Transaction</a> in the <a data-quicklook-from="arbitrum-chain">Arbitrum chain</a>'s inbox. An Arbitrum rollup provides data access by posting the data (in batched, compressed form) on L1 Ethereum as calldata. The Ethereum gas to pay for this is the largest component of cost in Arbitrum.
 
-AnyTrust relies instead on an external Data Availability Committee (hereafter, "the Committee") to store data and provide it on demand. The Committee has N members, of which AnyTrust assumes at least two are honest. This means that if N - 1 Committee members promise to provide access to some data, at least one of the promising parties must be honest. Since there are two honest members, and only one failed to make the promise, it follows that at least one of the promisers must be honest — and that honest member will provide data when it is needed to ensure the chain can properly function.
+AnyTrust relies instead on an external Data Availability Committee (hereafter, "the Committee") to store data and provide it on demand. The Committee has `N` members, of which AnyTrust assumes at least two are honest. This means that if `N - 1` Committee members promise to provide access to some data, at least one of the promising parties must be honest. Since there are two honest members, and only one failed to make the promise, it follows that at least one of the promisers must be honest — and that honest member will provide data when it is needed to ensure the chain can properly function.
 
 ## Keysets
 
-A Keyset specifies the public keys of Committee members and the number of signatures required for a <a data-quicklook-from="data-availability-certificate">Data Availability Certificate</a> to be valid. Keysets make Committee membership changes possible and provide Committee members the ability to change their keys.
+A Keyset specifies the BLS public keys of Committee members and the number of signatures required for a <a data-quicklook-from="data-availability-certificate">Data Availability Certificate</a> to be valid. Keysets make Committee membership changes possible and provide Committee members the ability to change their keys.
 
-A Keyset contains
+A Keyset contains:
 
 - the number of Committee members, and
 - for each Committee member, a BLS public key, and
@@ -40,7 +40,7 @@ A central concept in AnyTrust is the Data Availability Certificate (hereafter, a
   - a bitmap saying which Committee members signed, and
   - a BLS aggregated signature (over the BLS12-381 curve) proving that those parties signed.
 
-Because of the 2-of-N trust assumption, a DACert constitutes proof that the block's data (i.e., the preimage of the hash in the DACert) will be available from at least one honest Committee member, at least until the expiration time.
+Because of the `2-of-N` trust assumption, a DACert constitutes proof that the block's data (i.e., the preimage of the hash in the DACert) will be available from at least one honest Committee member, at least until the expiration time.
 
 In ordinary (non-AnyTrust) Nitro, the Arbitrum <a data-quicklook-from="sequencer">Sequencer</a> posts data blocks on the L1 chain as calldata. The hashes of the data blocks are committed by the L1 Inbox contract, allowing the data to be reliably read by L2 code.