Submission of updates regarding Helium documentation

docs/architecture/hotspot-makers/mcc/compliance-committee.mdx

@@ -37,58 +37,31 @@ process.
 
 ---
 
-Manufacturing a Hotspot is a new frontier for most manufacturers. They haven’t dealt with
-decentralized systems, or the blockchain and its trustless implications and responsibilities. Those
-features, which on the whole are beneficial, also create a risk that unwary and unethical
-manufacturers develop and sell products that could negatively affect the network.
-
-The MCC’s mandate is to verify that manufacturers and their respective products meet the minimum
-functional requirements for a device to participate on the Network. This includes blockchain-related
-transactions, a check on relevant regulatory requirements for all radio hardware, and that the
-devices meet the minimum authentication, encryption, and security standards needed to protect the
-network. The MCC does not test for or enforce general product quality standards, ensure the overall
-quality of the product, or the manufacturing process. Nor does the MCC test products for optimized
-RF performance, only basic RF function is reviewed.
+Venturing into the realm of Hotspot manufacturing poses a novel challenge for most manufacturers. Many are unfamiliar with decentralized systems and the blockchain, along with their intricate nuances of trustlessness and associated responsibilities. While these features offer immense potential benefits, they also introduce a risk: the possibility that unsuspecting or unscrupulous manufacturers may produce and distribute products that could potentially compromise the integrity of the network.
+
+To address this concern, the MCC (Manufacturing Certification Committee) is tasked with a crucial mandate: to ensure that manufacturers and their products adhere to the minimum functional requirements essential for participation within the Network. This entails rigorous scrutiny of blockchain-related transactions, verification of compliance with relevant regulatory standards for all radio hardware, and confirmation that devices meet essential authentication, encryption, and security benchmarks necessary to safeguard the network. It's important to note that while the MCC diligently evaluates these technical aspects, it does not assess or enforce general product quality standards, oversee the overall product quality or manufacturing process, or conduct tests to optimize RF performance. Instead, the MCC focuses solely on verifying basic RF functionality to ensure compatibility with Network requirements.
 
 ## Summary
 
-The MCC tries to set manufacturers up for success by letting them know the _minimum_ standards they
-need to meet and perform a cursory (and NOT binding) check on pre-production units.
+The MCC endeavors to equip manufacturers for success by outlining the minimum standards they must meet and conducting a preliminary, non-binding assessment of pre-production units.
 
-The MCC reviews the manufacturers at the following points:
+The MCC's review process unfolds at key junctures:
 
-- When a new manufacturer makes its first application. Company information is submitted and reviewed
-  by the Helium Foundation and MCC.
-- Each new Helium compatible product that the manufacturer brings to market is reviewed by the MCC.
+- Upon the submission of a new manufacturer's initial application, where company information undergoes scrutiny by both the Helium Foundation and the MCC.
+- With the introduction of each new Helium-compatible product to the market, the MCC conducts a thorough evaluation.
 
-The review consists of:
+This evaluation encompasses:
 
-- Confirming that the appropriate radio certifications by country have been properly completed.
-- Performing hardware audits to ensure it _can_ interface with the blockchain.
+- Verification of proper completion of radio certifications required by respective countries.
+- Conducting hardware audits to ensure compatibility with blockchain interfacing.
 
-The sole power the MCC wields is a very blunt instrument, which is that the MCC can bestow or
-withdraw “maker keys”. In layman’s terms, the Maker’s Keys are the passcodes that allow a unit to be
-added to the blockchain. This is a blunt and weak instrument by design; no one unit or entity should
-be able to hold the entire ecosystem hostage. If an entity could selectively withdraw any hotspots
-or group of hotspots' ability to participate in earning blockchain rewards, that entity would hold
-tremendous and centralized power.
+The MCC's authority is wielded through the issuance or revocation of "maker keys," which serve as passcodes enabling units to be added to the blockchain. This mechanism is intentionally blunt and decentralized to prevent any single entity from exerting undue control over the ecosystem. If a maker were to selectively withhold the ability of certain hotspots or groups of hotspots to participate in earning blockchain rewards, it would amass disproportionate and centralized power.
 
-A manufacturer is not bound or controlled by the MCC, the only required inspection points are its
-initial manufacturer application approval and the subsequent submissions of Helium compatible
-products for MCC hardware audit and approval.
+It's important to note that manufacturers are not bound or controlled by the MCC beyond the initial approval of their manufacturer application and subsequent submissions of Helium-compatible products for hardware audit and approval.
 
-After being approved, a manufacturer may fail to meet either the technical, security, and/or ethical
-standards set by the MCC committee. The MCC reserves the right to reassess the conformance of all
-approved manufacturers and their Helium products at any time. If significant violations are found
-the MCC may suggest the manufacturer take specific corrective actions and/or at its sole discretion
-choose to suspend or permanently withdraw the manufactures “maker key(s)”. This will prevent the
-maker from deploying any new Hotspots to the Helium network.
+Post-approval, a manufacturer may fail to uphold the technical, security, and/or ethical standards set by the MCC. In such instances, the MCC retains the authority to reassess the conformity of all approved manufacturers and their Helium products at any time. If significant violations are identified, the MCC may recommend corrective actions and/or, at its discretion, opt to suspend or permanently revoke the manufacturer's "maker key(s)," thereby preventing the deployment of new Hotspots on the Helium network.
 
-Due to the nature of a decentralized ecosystem, the broader assessment of which manufacturers are
-delivering high-quality and/or high-performance products must be left to the Helium Community and
-natural market forces. This puts a majority of the responsibility of “buyer beware” on the
-purchaser, which is unlike many other centralized network-connected products which are directly
-supported by the “network operator”.
+Given the decentralized nature of the ecosystem, the broader evaluation of which manufacturers deliver high-quality and/or high-performance products falls to the Helium Community and natural market forces. This places the onus of "buyer beware" primarily on purchasers, unlike many other centrally operated network-connected products, which are directly supported by the network operator.
 
 ### **MCC Member Requirements:**
 

docs/architecture/hotspot-makers/mcc/maker-ethics.mdx

@@ -21,22 +21,11 @@ The community may raise ethics violation issues and send evidence to the Helium
 
 # Summary
 
-This ethics document is written by the Manufacturing Compliance Committee (MCC) to clearly document
-what the ethics expectations of manufacturers are. If a manufacturer fails to uphold the ethics and
-expectations outlined in this document, the Helium community reserves the right to take action
-against the manufacturer. The consequence will be decided on by the Helium community and may
-include: requests for more information, selling restrictions, temporary probation, or in extreme
-cases, revoking of a maker's key or a ban from the community.
-
-In order to achieve the collective goal of a global decentralized Helium network, large volumes of
-Hotspots are manufactured by a wide range of manufacturers. The existing HIP-19 application process
-and guidelines provide new and existing Helium Hotspot manufacturers specific guidance on the
-hardware design, configuration, security, and manufacturing requirements needed to become an
-approved Helium compatible Hotspot manufacturer.
-
-Only HIP-19 approved manufacturers are granted the trusted privilege to add new Hotspots to the
-Helium network. With this privilege, manufacturers are also entrusted with the responsibility to act
-ethically and with the proper internal processes to protect the integrity of the Helium network.
+This ethics document, authored by the Manufacturing Compliance Committee (MCC), serves as a comprehensive guide outlining the ethical expectations placed upon manufacturers within the Helium ecosystem. Should a manufacturer fail to adhere to the ethical standards delineated in this document, the Helium community retains the authority to initiate appropriate action against the manufacturer. Such actions may vary and could include requests for additional information, imposition of selling restrictions, temporary probationary measures, or in severe cases, the revocation of a maker's key or expulsion from the community.
+
+The collective pursuit of establishing a globally decentralized Helium network necessitates the manufacturing of large volumes of Hotspots by a diverse array of manufacturers. To streamline this process and ensure adherence to rigorous standards, the existing HIP-19 application process and guidelines furnish both new and existing Helium Hotspot manufacturers with specific directives pertaining to hardware design, configuration, security protocols, and manufacturing requisites essential for attaining approval as a Helium-compatible Hotspot manufacturer.
+
+Only manufacturers approved under the HIP-19 framework are entrusted with the esteemed privilege of adding new Hotspots to the Helium network. This privilege inherently entails a profound responsibility to conduct business ethically and uphold stringent internal processes aimed at safeguarding the integrity and stability of the Helium network.
 
 ---
 

docs/architecture/oracles/data-transfer-oracles.mdx

@@ -18,17 +18,9 @@ points of failure.
 
 ## LoRaWAN Network Server Streamlining
 
-In comparison with its operation on the Helium L1, the LoRaWAN Network Server (LNS) has a more
-focused role on Solana which emphasizes the execution of LoRaWAN specific functions without the
-overhead of administering blockchain-specific functionality. After purchasing Organizationally
-Unique Identifier (OUI) and slabs, the LNS must inform the Config Service of the routing for the
-devices under their network. The LNS can optionally curate an allow-list to, for example, not accept
-packets from disabled devices or tenants/devices with a depleted Data Credit (DC) balance. The LNS
-will directly transmit these routes and their allow-list to the Config Service.
-
-The update brings the responsibilities of a Helium LNS much more in line with a generic LNS while
-also easing the integrations of existing LNS systems, further helping the expansion of the Helium
-Network.
+In contrast to its operations on the Helium L1, the LoRaWAN Network Server (LNS) assumes a more refined role within Solana, prioritizing the execution of LoRaWAN-specific functions devoid of the overhead associated with administering blockchain-specific tasks. Post the acquisition of Organizationally Unique Identifier (OUI) and slabs, the LNS is mandated to communicate routing information for the devices within their network to the Config Service. Optionally, the LNS can curate an allow-list, enabling selective acceptance of packets, such as those originating from enabled devices or those with a sufficient Data Credit (DC) balance.
+
+This update aligns the responsibilities of a Helium LNS more closely with those of a conventional LNS, thereby simplifying integrations with existing LNS systems and facilitating the expansion of the Helium Network.
 
 ## Config Service
 

docs/architecture/oracles/oracles.mdx

@@ -15,14 +15,9 @@ import LegacyContentBanner from '@site/src/theme/LegacyContentBanner'
 
 <img className="docsheader" src={useBaseUrl('img/blockchain/oracle.png')} />
 
-The migration of the Helium L1 to the Solana L1 brings several changes to the setup of the Network
-and its associated subDAOs infrastructure. Chief among these changes is moving a lot of data that
-has previously been "on-chain" (namely PoC data) "off-chain".
-
-As such, this migration introduces several Oracles which serve as bridges between the external world
-and the blockchain. These infrastructure changes allow the Helium Network to effectively introduce
-new Networks as Decentralized Network Protocol (DNP) subDAOs, and more easily scale existing DNP
-subDAOs (e.g., IOT) by removing existing bottlenecks.
+The migration of Helium L1 to Solana L1 heralds significant alterations to the Network's setup and the underlying infrastructure of its associated subDAOs. Foremost among these changes is the relocation of substantial on-chain data, particularly Proof-of-Coverage (PoC) data, to an off-chain environment.
+
+In effecting this migration, several Oracles have been implemented to serve as vital conduits between the blockchain and the external realm. These pivotal infrastructure adjustments not only pave the way for the seamless introduction of new Networks as Decentralized Network Protocol (DNP) subDAOs but also facilitate the streamlined scaling of existing DNP subDAOs, such as IOT, by eliminating prevalent bottlenecks.
 
 With the deprecation of the Helium L1, changes to the API and
 [ETL](https://github.com/helium/blockchain-etl) include:

docs/architecture/oracles/rewards-oracles.mdx

@@ -22,22 +22,15 @@ every 24 hours by each Reward Oracle.
 
 ## Lazy Distribution of Rewards
 
-On the Solana L1, Rewards will now be "lazily distributed" to each Hotspot, meaning that instead of
-passively receiving tokens, Hotspot Owners will _redeem_ them.
+On the Solana L1, Rewards will adopt a "lazily distributed" approach, altering the dynamics for Hotspot Owners who will now actively redeem their tokens instead of receiving them passively.
 
-When a Hotspot Owner makes a redemption request, the Rewards Oracle will compute the difference
-between the `lifetime` and `claimed` token Rewards to determine the amount of unclaimed tokens per
-Hotspot. It will then pre-sign a transaction which the Hotspot Owner will submit to the blockchain.
-It is only at this point that Rewards will be registered on-chain and associated with the owning
-Helium Wallet.
+Upon a redemption request from a Hotspot Owner, the Rewards Oracle will calculate the disparity between the `lifetime` and `claimed` token Rewards to ascertain the unclaimed tokens per Hotspot. Subsequently, it will pre-sign a transaction, which the Hotspot Owner will then submit to the blockchain. It's crucial to note that Rewards will only be registered on-chain and linked with the respective Helium Wallet upon this submission.
 
 ## IOT Rewards Oracle
 
-The IOT Rewards Oracle combines the Verified PoC Receipts, the Verified IOT Data Transfer Receipts,
-and the veHNT backing the IOT Network and emits rewards to each Hotspot.
+The IOT Rewards Oracle integrates Verified PoC Receipts, Verified IOT Data Transfer Receipts, and the veHNT supporting the IOT Network to distribute rewards to individual Hotspots.
 
-As a reminder, the Data Transfer Verifier and the PoC Verifier already do much of the heavy lifting
-by including the shares each Hotspot should receive.
+It's worth noting that the Data Transfer Verifier and the PoC Verifier shoulder a significant portion of the workload by incorporating the allocation of shares for each Hotspot, thus streamlining the reward distribution process.
 
 ## MOBILE Rewards Oracle
 

docs/architecture/solana/migration-overview.mdx

@@ -14,14 +14,6 @@ import useBaseUrl from '@docusaurus/useBaseUrl'
 <br />
 <br />
 
-Following the community-driven proposal,
-[HIP70 - Scaling the Helium Network](https://github.com/helium/HIP/blob/main/0070-scaling-helium.md),
-the Helium Network was successfully migrated to the Solana blockchain on **April 18, 2023, 9am PST**
-(16:00 UTC). This strategic move, voted in by the community, let the Helium Network capitalize on
-Solana's scalability, low transaction costs, and high-performance capabilities, including fast
-transaction throughput and energy-efficient consensus mechanism.
+Following the community-driven proposal outlined in [HIP70 - Scaling the Helium Network](https://github.com/helium/HIP/blob/main/0070-scaling-helium.md), the Helium Network underwent a successful migration to the Solana blockchain on **April 18, 2023, at 9am PST** (16:00 UTC). This strategic decision, endorsed by the community, empowered the Helium Network to leverage Solana's remarkable scalability, low transaction costs, and high-performance capabilities, including rapid transaction throughput and an energy-efficient consensus mechanism.
 
-The migration to Solana brought many benefits for the Helium Network: it enabled the IoT and Mobile
-networks to support even greater scale, support more sophisticated Proof-of-Coverage algorithms, and
-enhanced the network's robustness, making it an even more attractive solution for high-demand
-applications.
+The transition to Solana ushered in numerous benefits for the Helium Network: it facilitated even greater scalability for the IoT and Mobile networks, enabled support for more sophisticated Proof-of-Coverage algorithms, and bolstered the network's resilience, rendering it an even more compelling solution for high-demand applications.