diff --git a/docs/architecture/hotspot-makers/mobile-cbrs/5g-hardware-specification.mdx b/docs/architecture/hotspot-makers/mobile-cbrs/5g-hardware-specification.mdx deleted file mode 100644 index 8d7d58166..000000000 --- a/docs/architecture/hotspot-makers/mobile-cbrs/5g-hardware-specification.mdx +++ /dev/null @@ -1,211 +0,0 @@ ---- -id: 5g-hardware-specification -title: 5G Hotspot Hardware Specification -pagination_label: 5G Hardware Specification -sidebar_label: 5G Hardware Specification -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/mobile-cbrs/5g-hardware-specification ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' -import LegacyContentBanner from '@site/src/theme/LegacyContentBanner' - - - -## 5G Hotspot Minimum Specifications - -| Component | Minimum Requirement | -| -------------- | ---------------------------------------------------------------------------------- | -| CPU | x86_64 Linux compatible, 2.42 GHz Quad Core suggested, Must be TPM 2.0 compliant\* | -| RAM | 4 GB | -| Storage | 64 GB: Both SATA and NVME SSDs are supported | -| Secure Element | Enhanced Secure Element required | -| USB 3.0 | Required for imaging process | -| Software | Rust, Python, Magma (check Magma dependencies) | - -\* FreedomFi partners only. TPM 2.0 not required for non-Freedom Fi partners - ---- - -## Security - -Helium 5G/ Mobile Hotspots must have several security features in order to participate in the Helium -network and receive network rewards. These include a secure boot process and a secure element -feature for managing the cryptographic keys which identify the Hotspot on the network. - -### Secure Boot - -Helium 5G/ Mobile Hotspots must only run authenticated firmware that has been provided by the -manufacturer. This authentication process ensures that the Hotspot can be trusted by the rest of the -network. This is especially important in the 5G network because Hotspots make observational reports -on behalf of the entire network, such as: - -- User Equipment ("UE") attachment events -- Signal strength (RSSI, RSRP, RSRQ) -- Upstream bandwidth measurements - -Observational reports are ripe for “gaming” by the Hotspot owner because they directly impact the -rewards that the Hotspot will receive. - -When designed and used correctly, a secure boot process can overcome these problems, leading to a -more resilient and trustable network. - -### Secure Boot Requirements - -To be effective, the secure boot process you propose must meet these requirements: - -- There must be a secure hardware boundary encompassing: - - A boot CPU - - A one-time programmable memory area capable of storing: - - A trusted public key (or hash of such a key) for authenticating external boot code. - - A device-unique secret key - - A cryptographic hardware element capable of public key and private key cryptography. - - An unalterable (fused or masked) boot ROM. - - A static RAM. -- The buss(es) within the secure hardware boundary must be protected. - - Activity on the bus cannot be inspected nor altered by any entity outside of the boundary. - - No outside entity shall be able to inspect the device-unique secret key in unencrypted format. - - No outside entity shall be able to alter the contents of the memory elements (SRAM, boot ROM, - OTP memory) inside the boundary. - -### Secure Update Process - -A manufacturer-controlled process encompassing: - -- The external boot code signing key (private portion). -- A process for securely managing access to the signing key to trusted employees. - ---- - -## Enhanced Secure Element - -Helium has always required a Secure Element for all Hotspots that participate in LoRaWAN (soon to be -IOT) PoC rewards. This requirement will continue with the 5G network, however, the security -requirements for 5G will be more strict than what is in place for LoRaWAN. To prevent confusion, -these new requirements are known as **Enhanced Secure Element**. - -An Enhanced Secure Element is one which performs cryptographic digital signature and shared secret -derivation (currently ECDSA & ECDH) and does so _only at the request of the verified and trusted -firmware on the Hotspot_. This requirement effectively means that the secure element must be bound -the secure boot process. - -### Enhanced Secure Element Binding - -The secure element needs to be installed in such a way that the identity (private key) inside the -element cannot be easily removable or swappable. For example, secure element placement in a socket, -PCI card, or any other device that is easily removable yet retains the private key after removal is -unacceptable. - -The secure element also should refuse to function unless it is under the control of the -manufacturer’s verified firmware. A secure element which continues to function when the firmware has -been altered or replaced is unacceptable. - -#### Enhanced Secure Elements Requirements Questionnaire - -When submitting your Hotspot design, please submit an Enhanced Secure Element amendment. The -amendment should be phrased: "HIP19 amendments for alternate security implementations" and should -answer these questions about the gateway’s private key: - -1. How is the private key loaded onto the device? (Is it generated on-device or is it imported - externally?) -2. Where is the device located when this happens? (Factory? A subsidiary? When booted by the - end-customer?) -3. What kind of non-volatile memory is used to store the private key? -4. Is the private key encrypted when it is stored in this memory? -5. If so, where is the key necessary to decrypt the encrypted private key stored? -6. Again, if the key is encrypted, does each device possess its own unique storage key, or is it - shared across all devices? -7. Again, if the key is encrypted, is there also a verification check to ensure that the key has - decrypted properly when it is loaded? -8. How is the trusted code loaded? -9. How is the code checked for authenticity when it is loaded? -10. Who in your organization has access to the keys used for signing this code? -11. Your implementation should have the ability to be updated. Please share the update method. -12. What specific signing, encryption, decryption, or verification operations can an external entity - ask the code to perform? (External entity means code _outside_ the secure element, such as, say, - the Helium “miner” process). -13. Considering the algorithms your implementation implements, are there certain operations/messages - that you are aware of that the code must never perform lest it leads to an exposure of the - private key? -14. Does the code protect against these messages/operations? -15. What side-channel attacks does your implementation work to avoid, if any? (As a reminder, - side-channel attacks extract key information from variations in timing, power, temperature, - electromagnetic fields, etc). -16. What fault-injection attacks does your implementation work to avoid, if any? (As a reminder, - fault-injection attacks include power-glitching, laser pulses, strong EM fields, etc). -17. Does the code have any entry point such that an external entity can ask for the private key - directly? -18. What steps have you taken to audit the code for quality and ensure that it performs only as - designed? -19. Do you, the developer of this code, have the ability to extract the private key of a device? -20. Will you, the developer of this code, have the ability to extract the private key of a device in - the future? - -Additionally, during the audit phase, please be prepared to provide an SDK and/or API (with header -files if in C) that exposes the two cryptographic functions that your engine performs, and the -source code to a simple program that uses this API to generate test signatures and Diffie-Hellman -key agreement. - ---- - -## Re-Auditing and Hotspot - -:::info - -A Maker should notify the Helium Foundation of any changes made to an approved Hotspot(s), even if -it does not require a re-audit or new HIP19 application. - -::: - -Indoor and Outdoor Hotspots with the same hardware layout arriving together will be audited together -(additional $500 fee). An example of this would be the same Hotspot model with the same hardware, -but one has an exterior case making it an outdoor unit. - -Different Hotspot models or indoor and outdoor Hotspots arriving at the same time with different -hardware layouts will require a separate hardware audit (additional audit fee). - -Indoor and Outdoor Hotspots arriving more than 2 weeks apart or with different hardware layouts will -be audited separately. - -### Re-Audit Requirements - -Re-audit (such as a change in model) will be required only if any of the following: - -- Change from an indoor model to an outdoor model -- CPU changes -- RAM **decreases** -- Storage **decreases** -- Change in **radio or radio location** - - No re-audit is required if one SX130x PCIe card with the same chipset is swapped for another, - such as SX1302 for SX1303. -- Change in security element -- Change in any parameter that requires regulatory recertification - ---- - -## Re-Voting on Radio Certification - -If manufacturers add additional radio certifications after the MCC's initial voting and approval -they will be invoiced for a fee of $2,000 (USD). All radio certifications must be in order prior to -the initial MCC voting process. Due to an increase in requests for Radio Certification approvals, -the MCC will only review new radio certifications once every 90 days for each manufacturer. - -Fees can also be reviewed -[here](https://github.com/dewi-alliance/hotspot-manufacturers#fees-in-usd-updated-december-2021). - ---- - -## Radio Certifications for China - -The MCC has voted (December 2021) to require radio certifications for China. Manufacturers will need -to provide radio certifications to be approved to sell in China. **Previously approved Hotspots will -have until May 1, 2022 to send in their radio certifications for China.** If radio certifications -are not provided by this date manufacturers will no longer be approved to sell to China. - ---- - -## Trusted Platform Module (TPM) reading - -- [TPM overview](https://www.duhocchina.com/wiki/en/Trusted_Platform_Module) -- [TPM wiki](https://wiki.archlinux.org/title/Trusted_Platform_Module) diff --git a/docs/architecture/hotspot-makers/mobile-cbrs/5g-hotspot-requirements.mdx b/docs/architecture/hotspot-makers/mobile-cbrs/5g-hotspot-requirements.mdx deleted file mode 100644 index 2db5f36be..000000000 --- a/docs/architecture/hotspot-makers/mobile-cbrs/5g-hotspot-requirements.mdx +++ /dev/null @@ -1,169 +0,0 @@ ---- -id: 5g-hotspot-requirements -title: 5G Hotspot Requirements -pagination_label: 5G Hotspot Requirements -sidebar_label: 5G Hotspot Requirements -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /hotspot-makers/mobile-cbrs/5g-hotspot-requirements ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' -import LegacyContentBanner from '@site/src/theme/LegacyContentBanner' - - - -:::info - -This document is the Hardware Audit procedure for 5G/CBRS Hotspots which have a FreedomFi -whitelabel. - -::: - -## Certification Process - -Certification will require two steps, both performed by the -[Manufacturing Compliance Committee](/hotspot-makers/compliance-committee) ("MCC"). - -1. Functional Certification. -2. System Certification. - -### Audit Process - -- Indoor and Outdoor Hotspots arriving together will be audited together. -- Indoor and Outdoor Hotspots arriving more than 2 weeks apart will be audited separately. -- Re-audit (such as change in model) required only if any of the following: - - CPU changes. - - RAM decreases. - - Storage decreases. - - Change in radio. - - Change in security element. - - Change in any parameter that requires regulatory recertification. - ---- - -## Functional Certification - -### Section 1: Hardware Unboxing and Review - -- Provide directions for how to change Orc8r to FreedomFi's Orc8r or give Foundation ssh access. -- Record date of audit. -- Record Model name and serial number. -- Link to vendor provided documentation. -- Link to HIP-19 proposal on Github. -- Link to Vendor website. -- List expected certifications (for CBRS, only FCC is relevant). -- Check antenna connector, must be reverse SMA. -- Unbox hardware and list what has been received (number received, Indoor/Outdoor). -- Record block diagram of system including the secure boot hardware: - - The diagrams should include all the hardware involved in the boot process and the security - boundaries of each component. - - Hardware items to illustrate include (but are not limited to): - - Cryptographic hardware accelerator - - Secure storage for private/secret and public keys - - Secure RAM - - Boot ROM - - Untrusted external RAM - - Untrusted external non-volatile storage (eMMC, SATA, etc) - - Communication busses - - The diagram must also show the security boundaries of your design. Group each component and bus - by the boundary it resides in. - - Image of PCB with secure security element clearly outlined - -### Section 2: Hardware Specifications - -- Does the hardware meet the specifications. -- Is the hardware the same in the HIP-19 application and on the manufacturer's website as what was - sent for the audit? -- Auditor may run one or more of the following to check hardware: - - Inspect CPU: `cat /proc/cpuinfo` - - Check memory: `free --mega` - - Check storage: `lsblk` - -### Section 3: Verify Secure Element Configuration - -Purpose of this section is to verify that the key is secure - -- Check firmware version is up to date: `sudo docker exec helium_miner_1 miner versions` - - _NOTE: In FreedomFi’s firmware, it is necessary to keep the miner image running when attempting - to run`gateway_mfr`. This is because the miner image has a helper daemon that `gateway_mfr` - needs to contact in order to “talk” to the TPM._ -- Query the Miner for its working keys/ verify that private and public are the same: - `sudo docker exec helium_miner_1 miner print_keys` -- Download the Miner from Helium's repo -- Query the TPM for its keys: - `docker exec helium_miner_1 /gateway_mfr --device "tpm://tpm/HS/SRK/MinerKey" test` to verify keys - match. - -### Section 4: RF Verification - -- Verify Manufacturue has RF Verification. -- Check US915 configuration file. - ---- - -## System Certification - -### Section 5: UE Connection To Network - -:::info Telecom Acronym - -User Equipment ("UE") refers to any device capable of connecting to the Internet, such as a phone, -tablet or computer. - -::: - -- Connect a UE Device to the CBRS network and perform activity such as downloading photos, sending - emails, and chat using Discord while using the 5G network. - - **Does the UE connect to the network and able to use it?** -- Verify that the UE is connected to the correct network by matching the IMSI and IP address: - `mobility_cli.py get_subscriber_table` - - **Is the UE connected to the expected network?** -- Verify that the UE is connected to the correct radio by matching the EARFCN and - CI:`sudo cat /var/opt/magma/configs/gateway.mconfig` - - Check the "enodebd" section for "cellId" and "earfcndl" numbers and compare them to the numbers - in Carrier Lab Dashboard (app for iOS) and/or About Phone in Android. - - **Is the UE connected to the expected radio and do the EARFCN and CI match?** -- Verify attach-detach with service request for single UE, can a single UE attach and detach from - the network? - - Using wireshark: - `ssh support@IP_ADDDRESS sudo tcpdump -i enodebr0 -U -s0 -w - 'not tcp port 22' | /Applications/Wireshark.app/Contents/MacOS/Wireshark -k -i -` - filter on sctp and put the UE in airplane mode, toggle and look for detach request - - **Is the UE able to leave and rejoin the network** - -### Section 6: Federation Gateway (FeG) and Magma connection - -- Verify that traffic is flowing through Magma rather than locally by sniffing traffic between radio - and AGW where GTP traffic is encapsulated. - - **Are source and destination IP showing 2-way traffic?** **Is there GTP traffic present?** -- Verify that traffic is flowing through the Foundation hosted Federation Gateway by looking at - messages that show that the UE's SIM card is getting checked by the Foundation's HSS. - - **Is the public IP of the Foundation hosted FeG present?** **Is the UE SIM card pointing at the - Foundation HSS?** - -### Section 7: UDP/ TCP traffic - -- Verify attach to network with uplink `UDP` data and then detach from network to show traffic - flowing inside of the GTP tunnel. - - Traffic flows from the UE to Google's DNS using `UDP`. - - Use **Wireshark** while browsing internet and filter on `udp.dstport == 53`. - - **Is traffic present in the GTP tunnel in 8.8.8.8.?** -- Verify attach to network with uplink `TCP` data and then detach from network to show traffic - flowing inside of the GTP tunnel. - - Traffic flows from the UE to Google's DNS using `TCP`. - - Use **Wireshark** while browsing internet and filter on `TCP`. - - **Is traffic present in the GTP tunnel?** - -### Section 8: UE Failure - -- Verify attach/ detach for two UEs - - Put 2 UEs into airplane mode and reconnect to internet in and out of airplane mode. - - Use **Wireshark** and filter on `sctp`. - - **Is attach/ detach messaging present?** -- Verify radio link failure for single or many UEs. - - Toggle airplane mode on UE, then leave it attached to the network (not in airplane mode) and - place it in a Faraday cage. - - This may be verified by using **Wireshark** and look for GUTI cleared/ IMEI cleared. - - This may also be verified by looking at the subscriber data with the timestamp before and after - `mobility_cli.py get_subscriber_table;date` - - **Does UE detach from network in simulated failure mode?** diff --git a/docs/architecture/solana/migration-faq.mdx b/docs/architecture/solana/migration-faq.mdx index 46f9781c7..10c30e024 100644 --- a/docs/architecture/solana/migration-faq.mdx +++ b/docs/architecture/solana/migration-faq.mdx @@ -12,26 +12,29 @@ slug: /solana/migration-faq ## Why Does My Account Have A Small Amount Of SOL? -Every migrated Wallet was seeded with a small amount, approximately 0.00139 SOL for -transactions, enough for roughly 100 transactions. The amount of SOL needs to be topped up and it is -recommended topping up with 0.1 and keeping it above 0.02 SOL. If the balance is between 0.01 and -0.001 SOL then transactions attempted on the blockchain may fail due to lack of funds. +Every migrated Wallet was seeded with a small amount, approximately 0.00139 SOL for transactions, +enough for roughly 100 transactions. The amount of SOL needs to be topped up and it is recommended +topping up with 0.1 and keeping it above 0.02 SOL. If the balance is between 0.01 and 0.001 SOL then +transactions attempted on the blockchain may fail due to lack of funds. ## Where Can I See My Hotspot's Activity And Rewards? -Oracle Data is available to application developers such as [Helium Geek](https://heliumgeek.com/), -[Moken](https://explorer.moken.io/), [Relay](https://app.relaywireless.com/explorer) and [Hotspotty](https://app.hotspotty.net/), who have built interfaces to monitor Hotspot -activity and rewards. +Oracle Data is available to application developers such as [Helium Geek](https://heliumgeek.com/), +[Moken](https://explorer.moken.io/), [Relay](https://app.relaywireless.com/explorer) and +[Hotspotty](https://app.hotspotty.net/), who have built interfaces to monitor Hotspot activity and +rewards. ## What Is The IOT Token? -Instead of earning HNT, LoRaWAN Hotspots will earn IOT rewards for their PoC and data transfer. -IOT can be swapped for HNT in the Helium Wallet app or on an exchange. Find more info about the [IOT](/tokens/iot-token) Token. +Instead of earning HNT, LoRaWAN Hotspots will earn IOT rewards for their PoC and data transfer. IOT +can be swapped for HNT in the Helium Wallet app or on an exchange. Find more info about the +[IOT](/tokens/iot-token) Token. ## How Do I Stake My HNT Tokens? -Staking HNT tokens uses the Helium Foundation created [Modular Governance](https://heliumvote.com/iot) and can be done directly in the Helium -Wallet app, by selecting the Governance Icon and selecting "Your Voting Power" +Staking HNT tokens uses the Helium Foundation created +[Modular Governance](https://heliumvote.com/iot) and can be done directly in the Helium Wallet app, +by selecting the Governance Icon and selecting "Your Voting Power" More instructions are available at [Staking on Helium Vote](/governance/staking-with-helium-vote). @@ -41,12 +44,13 @@ Here are 2 ways to do this: 1. On the home screen in the Helium Wallet App, there is an orange button for swapping tokens that leverages the Jupiter DEX. -2. Directly using a Decentralized EXchange (DEX) like [Jupiter](https://jup.ag) or [Orca](https://orca.so) +2. Directly using a Decentralized EXchange (DEX) like [Jupiter](https://jup.ag) or + [Orca](https://orca.so) :::warning -Please always check the swap or exchange rate before you confirm a transaction. You are responsible for -the confirmation of the exchange rate that is shown. +Please always check the swap or exchange rate before you confirm a transaction. You are responsible +for the confirmation of the exchange rate that is shown. ::: @@ -56,14 +60,14 @@ Rewards are distributed after each epoch, at approximately 1:30 AM UTC daily. Hotspots receive rewards for all the activity within an epoch as one sum. -Rewards must be claimed from Hotspots to wallets. And can be done individually per Hotspot or by claiming -from all hoptspots at once. +Rewards must be claimed from Hotspots to wallets. And can be done individually per Hotspot or by +claiming from all hoptspots at once. ## Is It Possible To Migrate A Wallet Without Having To Log Into The Helium Wallet App? -Yes, Wallets can be migrated directly within the Helium docs with -the online [migration widget](/solana/migration/exchange#mapping-helium-wallets-to-solana-wallets) or by -following manual instructions. +Yes, Wallets can be migrated directly within the Helium docs with the online +[migration widget](/solana/migration/wallet-user#migration-utility) or by following manual +instructions. Enter an old Helium address into the entry box and click the "Seed Wallet" button, give it a few seconds, and the Wallet will be migrated over to Solana. @@ -95,8 +99,8 @@ You can find the explanation for the two in the Helium Docs: Here are 3 ways you can get your new Helium address: 1. In the Helium Wallet App, Settings > Copy Address > Solana. -2. In the Helium Wallet App, on the tokens screen, click the copy symbol to the right of the address -above the wallet value. +2. In the Helium Wallet App, on the tokens screen, click the copy symbol to the right of the address + above the wallet value. 3. Using another service Foundation is providing, you can go to this URL, and it will return your new address. diff --git a/docs/architecture/solana/migration/application-builder.mdx b/docs/architecture/solana/migration/application-builder.mdx deleted file mode 100644 index ef9e463e6..000000000 --- a/docs/architecture/solana/migration/application-builder.mdx +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: application-builder -title: Application Builder Migration Guide -pagination_label: Application Builder -sidebar_label: Application Builder -description: Helium Application Builder Migration Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/application-builder ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' -import LegacyContentBanner from '@site/src/theme/LegacyContentBanner' - - - -As an application builder on top of Helium, many of the APIs and interfaces are changing. - -If you are building against Hotspots, token accounts, or anything blockchain related, you should -start with the [Primer on Solana](/solana/primer) and continue through the -[Solana docs](https://docs.solana.com/). - -If you are building against the Proof of Coverage datasets, you should read through the -[Data-Transfer Oracles documentation](/oracles/data-transfer-oracles). diff --git a/docs/architecture/solana/migration/blockchain-api.mdx b/docs/architecture/solana/migration/blockchain-api.mdx index af5bb209d..0ed2fd218 100644 --- a/docs/architecture/solana/migration/blockchain-api.mdx +++ b/docs/architecture/solana/migration/blockchain-api.mdx @@ -20,8 +20,8 @@ The data is also available as a torrent. | [Helium L1 Archive - Postgres Snapshot](/helium-l1-archive-postgres.torrent) (3.1 TB) | [Magnet Link](magnet:?xt=urn:btih:ac508205c440ac66d18d2f1755a7eb682a6c6549&dn=foundation-prod-etl-artifacts-v2&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Fopen.demonii.com%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.auctor.tv%3A6969%2Fannounce&tr=udp%3A%2F%2Fopentracker.i2p.rocks%3A6969%2Fannounce&tr=https%3A%2F%2Fopentracker.i2p.rocks%3A443%2Fannounce&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A6969%2Fannounce&tr=http%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Fopen.stealth.si%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.moeking.me%3A6969%2Fannounce&tr=udp%3A%2F%2Fexodus.desync.com%3A6969%2Fannounce&tr=udp%3A%2F%2Fuploads.gamecoast.net%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.tiny-vps.com%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.skyts.net%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker-udp.gbitt.info%3A80%2Fannounce&tr=udp%3A%2F%2Fopen.tracker.ink%3A6969%2Fannounce&tr=udp%3A%2F%2Fmovies.zsw.ca%3A6969%2Fannounce&tr=udp%3A%2F%2Fbt1.archive.org%3A6969%2Fannounce&tr=https%3A%2F%2Ftracker.tamersunion.org%3A443%2Fannounce&tr=https%3A%2F%2Ftracker.gbitt.info%3A443%2Fannounce) | | [Helium L1 Transactions & Blocks - CSV Export](/Helium_Txns_Archive.torrent) (724 GB) | [Magnet Link](magnet:?xt=urn:btih:090ff75cd0a834818c46f5a48483f45b37ac0199&dn=HeliumTxns&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Fopen.tracker.ink%3A6969%2Fannounce&tr=http%3A%2F%2Ftracker.opentrackr.org%3A1337%2Fannounce&tr=udp%3A%2F%2Ftracker.auctor.tv%3A6969%2Fannounce&tr=udp%3A%2F%2Fopentracker.i2p.rocks%3A6969%2Fannounce&tr=https%3A%2F%2Fopentracker.i2p.rocks%3A443%2Fannounce&tr=udp%3A%2F%2Fopen.demonii.com%3A1337%2Fannounce&tr=udp%3A%2F%2Fopen.stealth.si%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.torrent.eu.org%3A451%2Fannounce&tr=udp%3A%2F%2Ftracker.moeking.me%3A6969%2Fannounce&tr=udp%3A%2F%2Fexplodie.org%3A6969%2Fannounce&tr=udp%3A%2F%2Fexodus.desync.com%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker-udp.gbitt.info%3A80%2Fannounce&tr=https%3A%2F%2Ftracker.tamersunion.org%3A443%2Fannounce&tr=https%3A%2F%2Ftracker.gbitt.info%3A443%2Fannounce&tr=http%3A%2F%2Ftracker.gbitt.info%3A80%2Fannounce&tr=udp%3A%2F%2Fuploads.gamecoast.net%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.tiny-vps.com%3A6969%2Fannounce&tr=udp%3A%2F%2Ftracker.skyts.net%3A6969%2Fannounce&tr=udp%3A%2F%2Fretracker01-msk-virt.corbina.net%3A80%2Fannounce&tr=udp%3A%2F%2Fopentracker.io%3A6969%2Fannounce) | -For info on the historical DeWi ETL query tool, check the -[Blockchain ETL](/solana/migration/blockchain-etl) page. +For the historical DeWi ETL query tool, visit the archived +[Blockchain ETL](https://github.com/helium/blockchain-etl) repository. For ongoing access, the [Oracle Data](/oracles/oracle-data) and Solana blockchain represent Helium state after the migration. diff --git a/docs/architecture/solana/migration/blockchain-etl.mdx b/docs/architecture/solana/migration/blockchain-etl.mdx deleted file mode 100644 index 589325b19..000000000 --- a/docs/architecture/solana/migration/blockchain-etl.mdx +++ /dev/null @@ -1,23 +0,0 @@ ---- -id: blockchain-etl -title: Blockchain ETL -pagination_label: Blockchain ETL -sidebar_label: Blockchain ETL -description: Blockchain ETL -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/blockchain-etl ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' - -Upon the migration to Solana, the [Blockchain ETL](https://github.com/helium/blockchain-etl) halted -along with the Helium L1 blockchain. - -The Helium Foundation public ETL instance of Helium L1 data has been shut down. A full snapshot of -the Helium L1 has been retained and uploaded for public availability; see -[Blockchain API](/solana/migration/blockchain-api) page for access to these files. The -`#data-analysis` channel in the Helium Discord server can be a helpful resource when working with -these files. - -For ongoing insight into the operation of the Helium Network post-migration, please refer to the -[Oracle Data](/oracles/oracle-data) documentation. diff --git a/docs/architecture/solana/migration/blockchain-node.mdx b/docs/architecture/solana/migration/blockchain-node.mdx index e6fd27cd3..18aba4727 100644 --- a/docs/architecture/solana/migration/blockchain-node.mdx +++ b/docs/architecture/solana/migration/blockchain-node.mdx @@ -65,8 +65,8 @@ $ http -b https://migration.web.helium.io/migrate/13cQ6QUDvebHAppdmLYu9KXJvNZS9v 6. Submit the transactions to Solana. You can see typescript code demonstrating how to use this [here](https://github.com/helium/helium-program-library/blob/master/packages/migration-service/src/test-submit.ts#L37). -Alternatively, you can use the -[Migration Widget](/solana/migration/exchange#mapping-helium-wallets-to-solana-wallets) or +Alternatively, you can use the [Migration Widget](/solana/migration/wallet-user#migration-utility) +or [command line utility](https://github.com/helium/helium-program-library/releases/tag/v0.0.27-migration-cli) for steps 5-6. Example command provided below for the command line utility: diff --git a/docs/architecture/solana/migration/console-operator.mdx b/docs/architecture/solana/migration/console-operator.mdx deleted file mode 100644 index a09bed7e1..000000000 --- a/docs/architecture/solana/migration/console-operator.mdx +++ /dev/null @@ -1,18 +0,0 @@ ---- -id: console-operator -title: Console Operator -pagination_label: Console Operator -sidebar_label: Console Operator -description: Console Operator Migration -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/console-operator ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' -import LegacyContentBanner from '@site/src/theme/LegacyContentBanner' - - - -Please be advised that you must upgrade your instance of Helium Console to the latest version to -ensure the continued operation of devices managed by your LNS. Failure to upgrade before the Solana -Migration will result in interruptions to packet transfer for your devices. diff --git a/docs/architecture/solana/migration/exchange.mdx b/docs/architecture/solana/migration/exchange.mdx deleted file mode 100644 index 928f20ef1..000000000 --- a/docs/architecture/solana/migration/exchange.mdx +++ /dev/null @@ -1,170 +0,0 @@ ---- -id: exchange -title: Exchange Operator Migration Guide -pagination_label: Exchange Operator -sidebar_label: Exchange Operator -description: Helium Exchange Operator Migration Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/exchange ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' -import LegacyContentBanner from '@site/src/theme/LegacyContentBanner' - - - -:::warning Updated for Solana Mainnet - -The [Migration Widget](/solana/migration/exchange#mapping-helium-wallets-to-solana-wallets) and -description provided below have been updated to reflect Solana Mainnet. - -::: - -The Helium Network is migrating to the Solana blockchain. All Helium Network Tokens (HNT, IOT, and -MOBILE), will become [Solana SPL](https://spl.solana.com/token) tokens. - -If an exchange already supports SPL tokens, follow the steps below. - -:::tip SPL token Support - -Please refer to the Solana Documentation on how to -[Add Solana to Your Exchange](https://solana.com/docs/more/exchange) for details. - -::: - -## Mint IDs - -All Helium Network Tokens are available on the -[`TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA`](https://explorer.solana.com/address/TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA) -program, and mint IDs exist both on `mainnet-beta` and `devnet` for testing. - -The mint IDs are as follows: - -| Name | ID | -| ------ | ------------------------------------------- | -| HNT | hntyVP6YFm1Hg25TN9WGLqM12b8TQmcknKrdu1oxWux | -| MOBILE | mb1eu7TzEc71KxDpsmsKoucSSuuoGLv1drys1oP2jh6 | -| IOT | iotEVVZLEywoTn1QdwNPddxPWszn3zFhEot3MfL9fns | -| DC | dcuc8Amr83Wz27ZkQ2K9NS6r8zRpf1J6cvArEBDZDmm | - ---- - -## Mapping Helium Wallets to Solana Wallets - -Helium Wallets use the same ED25519 curve as Solana Wallets, resulting in Helium public keys and -secret keys mapping directly to Solana Wallets. - -You can either migrate your wallet using this widget: - -import { MigrateWallet } from '@theme/MigrateWallet' - - - -Or continue reading for manual instructions: - -### JavaScript - -To get the Solana public key equivalent of a Helium public key in javascript run: - - -```javascript -import Address from "@helium/address"; -import { PublicKey } from "@solana/web3.js" - -const addr = Address.fromB58("...helium pubkey..."); - -// Gets the solana pubkey -new PublicKey(addr.publicKey).toBase58() -``` - -To get a Solana equivalent `Keypair` from a Helium `Keypair`: - - -```javascript -import { Keypair } from "@helium/crypto"; -import { Keypair as SolanaKeypair } from "@solana/web3.js" - -const solanaKeypair = SolanaKeypair.fromSecretKey(heliumKeypair.privateKey); -``` - -### Rust - -In rust, to get a pubkey: - -```rust -let helium_pubkey_bytes = helium_pubkey.to_vec(); - -let solana_pubkey = solana_sdk::pubkey::Pubkey::new(&helium_pubkey_bytes[1..]); -println!("solana public key: {}", solana_pubkey); -``` - -To map a keypair: - -```rust -solana_sdk::signature::Keypair::from_bytes(helium_keypair.secret_to_vec()) -``` - -:::tip Migration API - -The Migration API can be used to retrieve the Solana Wallet address from a Helium Wallet address. - -`https://migration.web.helium.io/helium/*helium-wallet-address*` - -::: - ---- - -## Wallet Migration - -Wallets will need to be inflated on Solana. In essence this is recreating the Wallet's Helium state -on Solana. - -The -[migration-service](https://github.com/helium/helium-program-library/tree/master/packages/migration-service) -can be used to migrate wallet(s) to Solana. - -For the Helium Wallet app users, the Wallet requests the migration-service to get the needed -transaction and submits them to the Solana blockchain when the app is opened for the first time -after the Migration is complete. - -Since exchange Wallets may not use the Helium Wallet app, the migration service can instead be used -directly by following the below steps: - -For mainnet: - -1. Get the Solana Wallet address from a Helium Wallet address: - `https://migration.web.helium.io/helium/*helium-wallet-address*` - -2. Get the list of serialized transactions, which should be sent to Solana: - `https://migration.web.helium.io/migrate/*solana-wallet-address*?limit=1000&offset=0` - -3. Submit the transactions to Solana. You can see typescript code demonstrating how to use this - [here](https://github.com/helium/helium-program-library/blob/master/packages/migration-service/src/test-submit.ts#L37). - - Note: Each transaction is only allowed to execute once. - -Alternatively, you can use the -[command line utility](https://github.com/helium/helium-program-library/releases/tag/v0.0.27-migration-cli) -for steps 2-3. - -``` -$ env MIGRATION_SERVICE_URL=https://migration.web.helium.io env SOLANA_URL=https:/api.mainnet-beta.solana.com env SOLANA_WSS_URL=wss://api.mainnet-beta.solana.com ./migration-tx-executor --wallet *your-solana-wallet* -``` - -## Trustless Wallet Migration - -The tools listed above are convenient but rely on the migration service provided by the Helium -Foundation. - -The on-chain implementation of the migration is trustless, and the full state of the Helium -blockchain will be converted to a list of Solana transactions and compressed into a Merkle Tree root -on Solana. - -Any entity providing the proper proof that the provided transactions are valid can execute the -transactions to inflate a wallet. Each transaction is only allowed to execute once. - -If you would like a copy of the database serving the proofs for the migration service, please -[contact the Helium Foundation](mailto:hello@helium.foundation). - -This database copy can be used to run an instance of the -[migration service](https://github.com/helium/helium-program-library/tree/master/packages/migration-service) diff --git a/docs/architecture/solana/migration/governance.mdx b/docs/architecture/solana/migration/governance.mdx deleted file mode 100644 index 6b5a63b41..000000000 --- a/docs/architecture/solana/migration/governance.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -id: governance -title: Governance Migration Guide -pagination_label: Governance -sidebar_label: Governance -description: Helium Governance Migration Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/governance ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' -import LegacyContentBanner from '@site/src/theme/LegacyContentBanner' - - - -[Helium Vote][helium-vote] will transition to using [Solana SPL Governance Realms][realms]. - -While the user interface will change, the governance process will remain mostly the same. - -Using the Helium Wallet app, users will use an embedded browser to visit -[https://helium.vote][helium-vote], connect a Wallet, and vote yes/no on proposals. Ledger users, or -users of any other Solana Wallet, can also navigate to [https://helium.vote][helium-vote], connect a -wallet, and vote. - ---- - -## Governance Changes - -The major change with Solana governance is that more of the Helium Network can be governed by the -Helium Network and its subnetworks. Everything from Program (smart contract) changes to approving -Makers can now be controlled by the Helium DAO and its subnetworks. - -[helium-vote]: https://helium.vote -[realms]: https://app.realms.today diff --git a/docs/architecture/solana/migration/hotspot-maker.mdx b/docs/architecture/solana/migration/hotspot-maker.mdx deleted file mode 100644 index d6f32d5ac..000000000 --- a/docs/architecture/solana/migration/hotspot-maker.mdx +++ /dev/null @@ -1,402 +0,0 @@ ---- -id: maker -title: Maker App 2.0 Upgrade Guide -pagination_label: Hotspot Maker App -sidebar_label: Hotspot Maker App -description: Helium Hotspot Maker App Migration Docs -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/maker ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' -import LegacyContentBanner from '@site/src/theme/LegacyContentBanner' - - - -## Update and Add New Dependencies - -```json -"@helium/address": "^4.8.1", -"@helium/currency-utils": "^0.0.26", -"@helium/react-native-sdk": "2.0.0", -"@helium/wallet-link": "^4.8.3", -"@metaplex-foundation/mpl-bubblegum": "^0.6.2", -"@pythnetwork/client": "^2.11.0", -"@solana/web3.js": "^1.73.0", -"axios-retry": "^3.3.1", -"cipher-base": "^1.0.4", -"stream": "^0.0.2" -``` - ---- - -## Update App Providers - -Apps must now be wrapped in a `` and the `baseUrl` for `` has -changed - -A Solana Provider must be set with a Solana RPC. Because Helium makes use of Compressed NFTs, there -are currently 5 RPC providers with support: - -- [GenesysGo](https://genesysgo.com/) -- [Helius](https://helius.xyz/) -- [Triton](https://triton.one) -- [Shyft](https://docs.shyft.to/solana-rpcs-das-api/compression-das-api) -- [Hello Moon](https://docs.hellomoon.io/reference/rpc-endpoint-for-digital-asset-standard) - -You can visit their websites and get set up with an RPC url. - -```tsx -// src/App.tsx -const { walletLinkToken } = useSelector((state: RootState) => state.app) -const [heliumWallet, setHeliumWallet] = useState() - -useEffect(() => { - if (!walletLinkToken) { - if (heliumWallet) { - setHeliumWallet('') - } - return - } - - getAddress().then(setHeliumWallet) -}, [heliumWallet, walletLinkToken]) - -//////////////////////////////////////////////////// -//👇👇👇 new provider 👇👇👇 ///////////////////////// - - {/* ////////////////////////////////////////////////////////////// - Remove the /v2 from your onboarding url 👉👉👉👉👉👉👉👉👇 - ///////////////////////////////////////////////////////////👇 */} - - -{/* The Rest of your app... */} -``` - ---- - -## Testing Solana Pre-Migration - -Before the migration to Solana has been completed, the v2 onboarding server will be used, and -transactions will still be submitted to the Helium blockchain. To test Solana before transition, use -these variables: - -**_IT IS CRITICALLY IMPORTANT THAT YOU ONLY USE THESE FOR TESTING._** - -```tsx -// src/App.tsx - - -``` - -For testing against devnet, you can use our testing maker: - -``` -ONBOARDING_MAKER_ADDRESS="14neTgRNZui1hSiHgE3LXjSfwkPU8BEB192MLXXDFnSY2xKjH51" -ONBOARDING_AUTH_TOKEN="pk_TgclExRP7rEXAEQlSgrrDwaZUHJAPcw/nNfkEpWOPCk=:sk_E1xc9OVq1/5oKLGD4RzxST7bl+LMnJhalkQ3vZp/QbOjNltvAmHyPolzA0Pb2HyTD68mZp4lETuC19Y+vI72nA=" -ONBOARDING_MAKER_NAME="Test Maker" -``` - ---- - -## Onboarding a Hotspot - -When onboarding a Hotspot you must specify which `hotspotTypes` it supports (eg `iot` , `mobile`) - -You can optionally set `elevation`, `gain`, `lat`, and `lng` to avoid having to create a second -transaction. - -### Create Onboard Transactions - -`src/features/hotspots/setup/HotspotSetupConfirmLocationScreen.tsx` - -```tsx -const { getOnboardingRecord, getOnboardTransactions } = useOnboarding() - -let hotspotTypes = [] as HotspotType[] -const onboardingRecord = await getOnboardingRecord(params.hotspotAddress) -/* - TODO: Determine which network types this Hotspot supports - Could possibly use your maker address -*/ -if (Config.MAKER_ADDRESS_5G === onboardingRecord?.maker.address) { - hotspotTypes = ['iot', 'mobile'] -} else { - hotspotTypes = ['iot'] -} - -const onboardData = await getOnboardTransactions({ - txn: params.addGatewayTxn, - hotspotAddress: params.hotspotAddress, - hotspotTypes, - elevation, - decimalGain: gain, - lat, - lng, -}) - -// pre-solana this txn will exist -setAddGatewayTxn(onboardData.addGatewayTxn) - -// post-solana these txn(s) will exist -setSolanaTransactions(onboardData.solanaTransactions) -``` - ---- - -## Updating a Hotspot - -When updating a Hotspot you must specify which `hotspotTypes` it supports (eg `iot` , `mobile`) - -### Create transactions - -```tsx -// src/features/hotspots/setup/HotspotSetupConfirmLocationScreen.tsx -const { getAssertData, getOnboardingRecord } = useOnboarding() -const data = await getAssertData({ - decimalGain: gain, - elevation, - gateway: params.hotspotAddress, - lat, - lng, - owner: userAddress, - onboardingRecord, - hotspotTypes, -}) - -setAssertData(data) -setAssertLocationTxn(data.assertLocationTxn) -setSolanaTransactions(data.solanaTransactions) -``` - ---- - -## Transferring a Hotspot - -```tsx -// src/features/transferHotspot/TransferHotspot.tsx -const { createTransferTransaction } = useOnboarding() - -const { solanaTransactions, transferHotspotTxn } = await createTransferTransaction({ - hotspotAddress, - userAddress, - newOwnerAddress, -}) -``` - ---- - -## Linking to Helium Wallet app for Signing - -You must add `solanaTransactions` to the signature request - -`src/features/hotspots/setup/HotspotTxnsProgressScreen.tsx` - -```tsx -const updateParams = { - token, - platform: Platform.OS, - addGatewayTxn, - assertLocationTxn, - transferHotspotTxn, - solanaTransactions, // <---- !important! -} as SignHotspotRequest -const url = createUpdateHotspotUrl(updateParams) -Linking.openURL(url) -``` - ---- - -## Submit Signed Transaction(s) - -```tsx -// src/features/hotspots/setup/HotspotTxnsSubmitScreen.tsx -const { submitTransactions } = useOnboarding() -const { pendingAssertTxn, pendingGatewayTxn, pendingTransferTxn, solanaTxnIds } = - await submitTransactions({ - addGatewayTxn: params.gatewayTxn, - assertLocationTxn: params.assertTxn, - hotspotAddress: params.gatewayAddress, - solanaTransactions, - transferHotspotTxn: params.transferTxn, - }) -``` - ---- - -## Fetching Hotspots - -```tsx -const { getHotspots, getHotspotDetails } = useOnboarding() - -useEffect(() => { - getHotspots({ - heliumAddress, - // makerName: Config.MAKER_NAME, - }) -}, []) - -useEffect(() => { - getHotspotDetails({ - address: hotspot.address, - type: hotspotTypes[0], // The types you support ('IOT', 'MOBILE') - }) -}, []) -``` - ---- - -## Update Wallet Link - -The Helium Hotspot App is deprecated, Maker Apps should link to the Helium Wallet app. Add the hook -`useCheckWalletLink()` to `src/App.tsx` It will check to see if the user is linked to the Hotspot -app and prompt them to update their link - -```tsx -// src/App.tsx -import useCheckWalletLink from './utils/useCheckWalletLink' -const App = () => { - useCheckWalletLink() -} -``` - -Remove the ability for a new user to link to the Hotspot app. On the Welcome Screen you can now just -link directly to the black Helium Wallet app. - -```tsx -// src/features/onboarding/welcome/WelcomeScreen.tsx -const { walletApp } = useDelegateApps() - -const importAccount = useCallback(() => { - try { - const url = createWalletLinkUrl({ - universalLink: walletApp?.universalLink, - requestAppId: getBundleId(), - callbackUrl: 'makerappscheme://', - appName: 'Maker App', - }) - - Linking.openURL(url) - } catch (error) { - // eslint-disable-next-line no-console - console.error(error) - } -}, [walletApp?.universalLink]) -``` - ---- - -## New Android 13 Permissions - -Bluetooth scanning requires two new permissions on Android - -`AndroidManifest.xml` - -```xml - - -``` - -You must request these 3 permissions before scanning for bluetooth - -```tsx -const permissions = [ - PERMISSIONS.ANDROID.ACCESS_FINE_LOCATION, - PERMISSIONS.ANDROID.BLUETOOTH_CONNECT, - PERMISSIONS.ANDROID.BLUETOOTH_SCAN, -] -``` - -The Maker Starter is now using `react-native-permissions` to request/check permissions. If you'd -like to use the library, the setup guide can be found here: -https://github.com/zoontek/react-native-permissions - ---- - -## Data Credits and SOL for Onboarding - -:::info - -Maker Wallets will need both `SOL` for transactions on the Solana blockchain and `DC` for onboarding -fees post Migration. - -::: - -### Maker Wallet SOL - -Maker Wallets will need `SOL` to pay transaction fees and for minting new Hotspot NFTs. Note that -minting is only required if Makers are attempting to mint more than 2x their existing fleet size. - -- For most Makers, ~10 SOL is recommended. -- Makers with large fleets (300k+ Hotspots) ~60 SOL is recommended. - -#### Minting Cost Examples - -| Hotspots to Mint | SOL Needed | -| ---------------: | ---------: | -| 25,000 | ~14.8324 | -| 50,000 | ~29.4431 | -| 75,000 | ~58.6499 | -| 100,000 | ~58.6499 | - -For more insight to the amount of SOL needed, check out -[https://compressed.app/](https://compressed.app/) - -- Enter the number of Hotspots to mint in the `How many compressed NFTs do you want to store?` - field. -- The `Most composable, highest cost` value is a good approximation, round up when in doubt. - -
- Helium Wallet app token swap screen -
- -> Minting 100,000 Hotspots would require ~58.6499 SOL in this example. - -### Maker Wallet DC - -Maker Wallets will need `DC` to pay Helium onboarding and assert fees. DC can be acquired by either - -- Depositing DC into the Maker Wallet on the current Helium L1. -- Use the Helium Wallet app to swap HNT for DC. - -
-
-
- Helium Wallet app token swap screen -

- Use the Orange Swap button on the Helium Wallet app home screen to swap HNT for - DC. -

-
-
- Helium Wallet app token swap screen -

- Select HNT in the drop-down list to swap for DC. -

-

- Use the Maker Wallet in the recipient field. -

-
-
-
diff --git a/docs/architecture/solana/migration/hotspot-software.mdx b/docs/architecture/solana/migration/hotspot-software.mdx deleted file mode 100644 index 472883fd6..000000000 --- a/docs/architecture/solana/migration/hotspot-software.mdx +++ /dev/null @@ -1,163 +0,0 @@ ---- -id: maker-hotspot-software -title: Maker Gateway-rs Upgrade Guide -pagination_label: Hotspot Software -sidebar_label: Hotspot Software -description: Helium Hotspot Software Migration Docs -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/maker-hotspot-software ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' -import LegacyContentBanner from '@site/src/theme/LegacyContentBanner' - - - -As the miner image transitions to being a gateway-rs-only container, it will stop obeying settings -from the `sys.config` file that most Hotspot Makers use to notify the miner instance of Hotspot -settings. To help Makers with this transition, a list of common configuration items that were -previously configured via `sys.config` are provided along with alternates that will work for -gateway-rs. These configuration items can be set when invoking the miner container or when running -gateway-rs as a stand-alone executable. - -## Gateway-rs Configuration - -At startup, gateway-rs configures itself via two methods: from environment variables and from a -`settings.toml` file. By default, the settings file will be expected in the location -`/etc/helium_gateway/settings.toml`, but this can be overridden with the `-c` flag. However, it is -not recommended that Makers replace the default `settings.toml` file as it contains other important -key items that may change from time to time. Instead, we recommend that Makers supply any necessary -override items via _environment variables_. - -In general, any item in the `settings.toml` file can be overridden by supplying an environment -variable to gateway-rs with a name that is similar to the setting being overridden by prefixing the -settings keyword with the characters `GW_`. - -:::note Example - -To override the `keypair` item in `settings.toml` with the value `example://override`, supply the -environment variable `GW_KEYPAIR=example://override` to gateway-rs at startup. - -::: - -_Note:_ Previous versions of gateway-rs included both a `default.toml` and `settings.toml`. All -configurations are now only made in `settings.toml`. - -### Quick Reference Summary - -These are the configuration variables to migrate from miner to gateway-rs: - -| Erlang Source | Erlang Variable | gateway-rs Environment | Default Value | -| ------------- | -------------------- | ------------------------------------------ | ---------------- | -| `sys.config` | `miner:radio_device` | [`GW_LISTEN`](#packet-forwarder-bind-port) | `127.0.0.1:1680` | -| `sys.config` | `miner:jsonrpc_port` | `GW_API` | `127.0.0.1:4467` | -| `sys.config` | `blockchain:key` | [`GW_KEYPAIR`](#key-configuration) | None | -| Environment | `REGION_OVERRIDE` | [`GW_REGION`](#radio-region) | None | - -### Key Configuration - -Like the miner, gateway-rs requires a cryptographic key to identify and authenticate itself on the -Helium Network. Most Makers have likely relied on the default miner key settings, which instructed -the miner to use the cryptographic identity locked in slot 0 of an ECC608 chip on I2C bus #1 at I2C -address `0x60`/96. For these Makers this old default would have sufficed. - -Unlike the miner, however, gateway-rs does not have any default key setting. Therefore, as a Maker -you must specifically provide gateway-rs with an appropriate setting for your platform. - -If your platform deviated from the miner defaults, then you are likely familiar with the settings -that had to be adjusted in the `blockchain:key` override in sys.config. But, for the sake of -completeness, we'll illustrate all the settings that could have been adjusted in that scheme and -show how they are encoded in the scheme used by gateway-rs. - -For example, if the Erlang miner had been configured with: - -``` -{ blockchain, [ - { key, - { ecc, [ - {key_slot, 2}, - {onboarding_key_slot, 12}, - {bus, "i2c-5"}, - {address, 83} - ]} - } -]} -``` - -Then the equivalent gateway-rs ECC608 configuration would be via these two environment variables: - -``` -GW_KEYPAIR=ecc://i2c-5:83?slot=2 -GW_ONBOARDING=ecc://i2c-5:83?slot=12 -``` - -### Radio Region - -The region variable is the default region used when the Hotspot does not have an asserted location. -Makers need to ensure that the region is set correctly for the region in which the Hotspot is sold -to ensure correct beaconing behavior. - -Under the miner regime, the default radio region was adjusted via the `REGION` environment variable. -In gateway-rs it is specified via the `GW_REGION` environment variable. - -For example, if the Erlang miner had been configured to use the US915 region by default: - -``` -REGION=US915 -``` - -Then the equivalent gateway-rs configuration would be via the environment variable: - -``` -GW_REGION=US915 -``` - -### Packet Forwarder Bind Port - -The default address at which gateway-rs listens for UDP packets from the packet forwarder has not -changed (host `127.0.0.1`, port 1680). However, if you need to change the host or port binding from -this default then you will need to supply a `GW_LISTEN` environment variable. - -For example, if the Erlang miner had been configured with: - -``` -{miner, [ { - {radio_device, {{0, 0, 0, 0}, 1699, deprecated, deprecated}} -``` - -then the equivalent gateway-rs configuration would be via the environment variable: - -``` -GW_LISTEN=0.0.0.0:1699 -``` - -## Logging - -Before the migration, miner handled writing logs to disk. Post migration, helium_gateway outputs on -`stdout` as it has before. It is up to the Maker to integrate with their system's logging setup. -Capturing log output and writing to disk may be handled with a log manager such as `journald` or -`syslogd`. - -## CLI - -The CLI has changed for a few commands, notably the `helium_gateway info` command that some makers -may use now takes a list of info entries to return. The `helium_gateway info --help` output -documents what keys are available. - -## System Startup - -Since gateway-rs no longer releases as an installable package it is up to the maker to integrate the -executable with their system startup setups, (like procd or tini, systemd depending on the operating -system setup) - -## Firewall Configurations - -Makers using outbound firewall rules to restrict outbound connections should allow the following -outbound ports: - -| Purpose | Outbound Port Used | -| --------------------- | ------------------ | -| Configuration Service | TCP/6080 | -| Entropy Oracle | TCP/7080 | -| Packet Router | TCP/8080 | -| Packet Ingest | TCP/9080 | diff --git a/docs/architecture/solana/migration/network-user.mdx b/docs/architecture/solana/migration/network-user.mdx deleted file mode 100644 index 43a366190..000000000 --- a/docs/architecture/solana/migration/network-user.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -id: network-user -title: Network User Migration Guide -pagination_label: Network User -sidebar_label: Network User -description: Helium Network User Migration Documentation -image: https://docs.helium.com/img/link-image.png -slug: /solana/migration/network-user ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' -import LegacyContentBanner from '@site/src/theme/LegacyContentBanner' - - - -As a LoRaWAN Network user, you will not need to do anything during the migration. The network should -continue to function. Data transfer should be unaffected during the Solana Migration. - -During the Solana Migration, users may still purchase Data Credits with a credit card on Console. -However, users will be unable to acquire DC through a direct HNT burn on Console. If you need -additional Data Credits and prefer to burn HNT, please consider doing so before the 4/18 Solana -Migration. - -Core developers will actively monitor Network performance to ensure that systems stay operational. -If you believe that data transfer have been negatively impacted, please post the issue in the -#console channel in the [Helium Discord](https://discord.gg/helium). - - diff --git a/docs/architecture/solana/migration/wallet-user.mdx b/docs/architecture/solana/migration/wallet-user.mdx index e974e063a..bd426ec15 100644 --- a/docs/architecture/solana/migration/wallet-user.mdx +++ b/docs/architecture/solana/migration/wallet-user.mdx @@ -172,9 +172,8 @@ Mainnet after the migration window. Given the usage of the Merkle Tree, however, you will need to "inflate" or "seed" your Solana-mapped Helium Wallet on Solana. To do so, there is a **passive means** provided by the Helium Wallet App, -or an **active means** using the -[Migration Widget](/solana/migration/exchange#mapping-helium-wallets-to-solana-wallets) provided in -the documentation. +or an **active means** using the [Migration Widget](/solana/migration/wallet-user#migration-utility) +provided in the documentation. Regarding the **passive means**, you can simply export your Helium private key from the Helium CLI Wallet and import the Helium private key into the Helium Wallet App in the manner described in steps @@ -184,10 +183,9 @@ be inflated on Solana. After that point, you can use the Helium Wallet app to se transactions on Solana Mainnet. Regarding the **active means**, you can use the -[Migration Widget](/solana/migration/exchange#mapping-helium-wallets-to-solana-wallets). With the -Migration Widget, you need to provide your Helium or Solana-mapped Helium public key into the -Widget, then click the `Seed Wallet` button. After doing so, your Solana-mapped Helium Wallet on -Solana will be inflated. +[Migration Widget](/solana/migration/wallet-user#migration-utility). With the Migration Widget, you +need to provide your Helium or Solana-mapped Helium public key into the Widget, then click the +`Seed Wallet` button. After doing so, your Solana-mapped Helium Wallet on Solana will be inflated. _Please note that the Widget as currently provided operates on the Solana Devnet environment but will be changed to Solana Mainnet during the migration window._ diff --git a/docs/governance/image.png b/docs/governance/image.png deleted file mode 100644 index 3eece506f..000000000 Binary files a/docs/governance/image.png and /dev/null differ diff --git a/docs/governance/phase-1.mdx b/docs/governance/phase-1.mdx deleted file mode 100644 index bb9e6e5a1..000000000 --- a/docs/governance/phase-1.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -id: phase-1 -title: Phases of Helium Governance -pagination_label: Phases of Helium Governance -sidebar_label: Phase 1 Voting in Discord -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /governance/phase-1 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' -import LegacyContentBanner from '@site/src/theme/LegacyContentBanner' - - - -## Phase 1: Voting in Discord - -When the Community was using Discord for voting, the participation was low, and developers -prioritized ‘shipping code’ for quick changes to the protocol. Discord votes often happened through -hand-raising, represented by tools available in the chat application. - -### Where can I see what was voted on? - -HIP 1 to HIP 38 were voted on through Discord. Not all HIPs between HIP 1 to HIP 38 became proposals -that the community voted on. Some were closed, abandoned, or withdrawn by the Authors. You can check -the final status of these HIPs in the README at www.github.com/helium/hip. Each HIP has a -corresponding Tracking Issue holding more information about the events around a HIP. - -Each HIP has a corresponding HIP Discussion Channel in the Helium Discord. You can read the entire -chat of discussion in the “HIP-ARCHIVE-1” section of Discord here: https://discord.gg/helium - -### Where can I see the results of the votes? - -The Community documented the outcome of Discord votes in the Helium HIP Repository on GitHub. You -can review the results under README at www.github.com/helium/hip. - -Related program deployment history can be found on the Tracking Issue ticket itself. Each HIP has a -Tracking Issue associated with it that can be found linked in the “Status” section of the README -(linked above). The code of the Helium Network is available in the Helium Repository. The Repository -is fully open-source and available for public review: www.github.com/helium. - -### How can I see how each user/wallet individually voted? - -At this time, the Helium Community did not conduct wallet voting. From HIP 1 to HIP 38, you cannot -view voting results by an individual. - -### How do I vote? - -The Helium Community no longer votes through Discord. diff --git a/docs/governance/phase-2.mdx b/docs/governance/phase-2.mdx deleted file mode 100644 index 4470f7d65..000000000 --- a/docs/governance/phase-2.mdx +++ /dev/null @@ -1,59 +0,0 @@ ---- -id: phase-2 -title: Phases of Helium Governance -pagination_label: Phases of Helium Governance -sidebar_label: Phase 2 Helium Vote -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /governance/phase-2 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' -import LegacyContentBanner from '@site/src/theme/LegacyContentBanner' - - - -## Phase 2: Helium Vote - -As the Helium Network quickly grew, the Community moved to utilize their custom form of on-chain -voting with Heliumvote.com (also, https://helium.vote/). This became the sole platform for proposal -voting from November 2021 until the blockchain migration on April 18th, 2023. Users cast an on-chain -vote by submitting a Data Credit (DC) burn transaction. The movement to on-chain voting was a step -to mature the Helium Community voting processes and formalize voting with an immutable record. - -### Where can I see what was voted on? - -Heliumvote.com holds all the past results of proposal voting on the Helium L1 Blockchain, starting -with HIP 39 and ending with HIP 81. There, you can view proposals, how many votes were submitted, -and the HNT weight represented in voting populations. The source code can be found here: -www.github.com/helium/helium-vote. - -### Where can I see the results of the vote? - -You can see the results of the vote on Heliumvote.com directly. Each proposal that was voted on will -be found under “Closed Votes”. - -### How can I see how each user/wallet individually voted? - -Users can query the old Helium Blockchain through a publicly supplied data analytics tool hosted on -Metabase: https://etl.dewi.org/. - -Additionally, during the helium.vote phase of voting, users submitted Data Credit (DC) burn -transactions to a Helium-specific wallet address to cast their on-chain vote. This allowed -helium.vote to query each wallet address for all transactions and display total vote numbers for -“For” or “Against” vote tallies. - -These wallet addresses with DC burn transactions can be read by examining the open-source code -within the helium-vote Repository: www.github.com/helium/helium-vote and utilizing the legacy Helium -Explorer to query the old Helium Blockchain. - -Read more about the Legacy API and Explorer Shutdown on the DevBlog -[here](/devblog/2023/07/19/legacy-api-shutdown). - -If you would like to review the results of a vote by individual wallet, feel free to utilize these -instructions above or reach out to the Helium Foundation for assistance. - -### How do I vote? - -All voting ceased to function on Helium Vote on April 18th, 2023, when the Helium Community migrated -to the Solana Blockchain. As of April 18th, 2023, all voting is conducted on Realms. diff --git a/docs/governance/phase-3.mdx b/docs/governance/phase-3.mdx deleted file mode 100644 index a9caa07a5..000000000 --- a/docs/governance/phase-3.mdx +++ /dev/null @@ -1,135 +0,0 @@ ---- -id: phase-3 -title: Phases of Helium Governance -pagination_label: Phases of Helium Governance -sidebar_label: Phase 3 Realms on Solana -description: Helium Documentation -image: https://docs.helium.com/img/link-image.png -slug: /governance/phase-3 ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' -import LegacyContentBanner from '@site/src/theme/LegacyContentBanner' - - - -## Phase 3: Realms on Solana - -Realms is the most recent and current phase of Helium Governance. Realms is a Solana native tool for -decentralized governance. This tool replaces the previously used Helium Vote system. It is the -platform adopted by the Helium Community in the passing of HIP 70 and includes features for staking, -delegating, and on-chain voting. HIP 70 defined the Vote Escrowed model of token holder voting as -the next phase for Helium Governance. - -Realms enables token holders to actively participate in the governance process by staking their -tokens and casting votes on proposed changes and decisions. - -### Where can I see what was voted on? - -You can view past and current proposals on Realms by navigating to either the Helium Network or -subnetworks at: - - - -- Helium (HNT): [realms.heliumvote.com/dao/hnt](https://www.realms.heliumvote.com/dao/hnt) -- IoT subnetwork (IOT): [realms.heliumvote.com/dao/iot](https://www.realms.heliumvote.com/dao/iot) -- Mobile subnetwork (MOBILE): - [realms.heliumvote.com/dao/mobile](https://www.realms.heliumvote.com/dao/mobile) - -You’ll also always find the in progress and final statuses in the Helium HIP Repository at: -www.github.com/helium/hip. - -### Where can I see the results of the vote? - -You can view all past and current results of a vote on Realms by navigating to the links above and -clicking directly into the proposal. Programs deployed in relation to these proposals can be found -in the helium-program-library and within the full open-source Helium Repository at: -www.github.com/helium. - -### How can I see how each user/wallet individually voted? - -The Realms “Explore” tab allows you to search for votes by wallet address. Please note that Helium -Network's rules for voting differ from the default rules on Realms. As a result, viewing the results -on realms.today is not representative of the actual outcome under the Helium Network's rules for HIP -voting. For the correct results, please make sure to view them on GitHub. - -The results of a proposal vote can also be reviewed by querying the Solana Blockchain and related -spl-governance contracts. - -You can view the Helium governance contracts on Solana here: - - - -#### Contract for delegation of tokens to subnetworks for rewards - -``` -hdaoVTCqhfHHo75XdAMxBKdUqvq1i5bF23sisBqVgGR -``` - -#### Default spl-governance contract to govern our own contracts and council - -``` -hgovkRU6Ghe1Qoyb54HdSLdqN7VtxaifBzRmh9jtd3S -``` - -#### Contract for governance to create Helium-specific voting power rules - -``` -hvsrNC3NKbcryqDs2DocYHZ9yPKEVzdSjQG6RVtK1s8 -``` - -### How do I vote? - -Any token holder is eligible to vote. Token holders may go through different steps to vote depending -on their level of onboarding and familiarity with the Solana Blockchain. - -Users need to have one of the Helium Network or subnetwork Tokens: HNT, IOT, or MOBILE. After this, -they need to be familiar with the Solana Network and have a Solana-compatible wallet. A wallet -allows users to interact with applications that utilize the Blockchain as a backend for data -storage. A wallet is straightforward to use and generally is a mobile application or browser plugin -for easy interactions with websites. - -After a user has their wallet, they must acquire some SOL to complete transactions on the Solana -Blockchain. SOL is the native token of the Solana Blockchain and is required to use and store data -on the blockchain. The amount of SOL required per transaction depends on if a user is completing a -one-time transaction with a small amount of data or is storing data for a longer amount of time that -will need to be called later. - -Once a user is onboarded with a wallet, Helium tokens, and some SOL for transactions, they can begin -using and interacting with Realms, the Helium Network’s tool for voting. When a user is ready to use -Realms, they will need to lock or stake their tokens for voting power, creating a vote escrowed -position with their tokens. This vote escrowed position gives them the ability to cast votes on any -active proposals for the Helium Network or subnetwork they let you quickly. - -**A detailed step-by-step description of moving from onboarding to voting is outlined below. All -steps that may require the signing of a transaction are noted as such:** - -1. Establish an account on a Solana-compatible wallet. The Helium Wallet is a recommended choice - built for Helium users specifically, but any Solana-compatible wallet will perform all the - functions you need. -2. Acquire tokens by providing coverage for the network or through a liquidity provider in the - Solana Ecosystem. The tokens you have depend on the network you are providing coverage for or the - Network or subnetworks you wish to participate in the governance of (HNT, IOT, or MOBILE). - _Requires signing a transaction_ -3. Acquire SOL to perform transactions on the Solana Blockchain. _Requires signing a transaction_ -4. Navigate to Realms at the addresses above. -5. Connect your wallet. _Requires signing a transaction_ -6. Navigate to “my governance power.” -7. Select “Lock Tokens”. This is how you stake tokens for voting power. -8. Follow the on-screen instructions to “Lock” your tokens. You can lock as little as one token or - as many as you have. -9. You can choose up to 4 years to lock or as little as six months. -10. You will need to choose “Decaying” or “Constant” -11. Decaying means the lockup period begins to countdown immediately. -12. Constant means the lockup period will remain until the user decides to start the countdown. -13. Select “Lock Tokens” to complete the action. _Requires signing a transaction _ -14. Locate an active proposal. -15. Cast your vote with options “Yes” or “No”. _Requires signing a transaction_ - -A step-by-step user guide to staking on Realms can be found in Helium Docs: -[here](/governance/realms) - -View the index of past HIP decisions on Github -[here](https://github.com/helium/HIP#helium-improvement-proposals-hip) - -View the index of implemented HIPs on Docs [here](https://docs.helium.com/hip#implemented-hips) diff --git a/docs/governance/realms.mdx b/docs/governance/realms.mdx deleted file mode 100644 index b9300114e..000000000 --- a/docs/governance/realms.mdx +++ /dev/null @@ -1,89 +0,0 @@ ---- -id: realms -title: Realms -pagination_label: Realms -sidebar_label: Realms -description: Helium Documentation -slug: /governance/realms ---- - -import useBaseUrl from '@docusaurus/useBaseUrl' -import LegacyContentBanner from '@site/src/theme/LegacyContentBanner' -import { ConnectImg, TestVoteImg } from '@site/src/theme/RealmsPage' - - - -To approve or deny changes to the blockchain, economics, or governance of the Helium Network; The -Helium Network leverages on-chain voting which is open to the entire community. This on-chain voting -is facilitated through the website [Realms][realms]. - ---- - -## How to Vote on Realms - -Like many other Solana Ecosystem projects, Helium uses Realms to organize and manage governance, -vote escrowed tokens, delegation, and more. Using the links below, you can cast your vote for the -subnetwork of which you seek to impact and contribute to. - -Ensure that you have a Solana-ready wallet that is funded with some SOL and one of the network -tokes: HNT, IOT, or MOBILE. - - - -### Signing Into Realms - -Use your account that holds your veHNT positions to sign in to Realms. The same account can be used -for all platforms, but it must have veTokens for the specific DAO or subnetwork hosting the vote. - -The links for the Realms governance portals are: - -- [https://realms.heliumvote.com/dao/hnt][realms-hnt] -- [https://realms.heliumvote.com/dao/iot][realms-iot] -- [https://realms.heliumvote.com/dao/mobile][realms-mobile] - -Sign in to these using the in-app browser from the Helium Wallet App. - - - -### Casting Your Vote - -After you have reviewed the proposal, casting your vote is as easy as issuing a Solana transaction -for "Yes" or "No". - -Note: You will need a bit of Sol to cast your veTokens for a vote. - -
-
- - -
-
After voting, you can leave a comment supporting your stance.
-
- -### Understanding Vote Power - -When you vote your veTokens, all positions will be attributed to your vote choice. Token positions -cannot be split within one vote on a single account. - -Your vote is calculated at the time your vote is submitted. If your position is in 'decay' mode, -voting sooner means you apply greater voting power. Conversely, if a position is extended to added -to, a vote can be relinquished and re-voted to apply the new voting power. - -
- -
A vote can be changed by first relinquishing it.
-
- -[realms]: https://realms.today -[realms-hnt]: https://realms.heliumvote.com/dao/hnt -[realms-iot]: https://realms.heliumvote.com/dao/iot -[realms-mobile]: https://realms.heliumvote.com/dao/mobile -[discord]: https://discord.gg/helium -[staking]: /staking-with-helium-vote -[swap-utility]: /sol-token#swap-utility diff --git a/docs/home/faq/build-on-network.mdx b/docs/home/faq/build-on-network.mdx deleted file mode 100644 index e52613786..000000000 --- a/docs/home/faq/build-on-network.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -id: build-on-network -title: Build on the IOT Network FAQ -pagination_label: Build on the IOT Network FAQ -sidebar_label: Build on the IOT Network FAQ -description: Build on the Helium IOT Network -image: https://docs.helium.com/img/link-image.png -slug: /home/faqbuild-on-network ---- - -import LegacyContentBanner from '@site/src/theme/LegacyContentBanner' - -# FAQ - Build On Network - - - -## I want to use the Helium Network for my IoT project. How do I learn more? - -Thanks for your interest! Join the [community Discord server](https://discord.gg/helium) as there -are several channels dedicated to development. There’s also -[extensive documentation on using the Network](/iot). - - - -## Can end devices communicate directly with each other or do they have to hop over the Helium Hotspot? - -All compatible devices communicate via Hotspots. There is no direct communication or meshing in the -Helium Network. - - - -## Will Helium be proprietary? - -We believe proprietary protocols and technologies stifle innovation. This is why we use commodity, -open-standard hardware, and modules available from dozens of vendors. And all software used is -[open source under friendly licenses](/faq/open-source). - -## What kind of data rates do you anticipate going from device to the Hotspot? - -Applications that are suitable for the Helium Network send small amounts of data. The maximum amount -possible is around 5kbits per second. But this is rarely seen in production. Typically sensors are -sending 10-1000 bytes at a time. - - diff --git a/sidebarsDocs.js b/sidebarsDocs.js index 36ec229e4..d1d470446 100644 --- a/sidebarsDocs.js +++ b/sidebarsDocs.js @@ -143,7 +143,6 @@ module.exports = { }, items: [ 'architecture/hotspot-makers/hotspot-makers', - 'architecture/hotspot-makers/mobile-cbrs/5g-hardware-specification', 'architecture/hotspot-makers/mcc/compliance-committee', 'architecture/hotspot-makers/mcc/maker-ethics', 'architecture/hotspot-makers/become-a-maker/on-chain-maker-creation', @@ -179,7 +178,6 @@ module.exports = { }, 'home/faq/helium-network', 'home/faq/security', - 'home/faq/build-on-network', ], collapsed: true, }, @@ -205,19 +203,10 @@ module.exports = { link: { type: 'doc', id: 'architecture/solana/migration-overview' }, items: [ 'architecture/solana/migration-faq', - 'architecture/solana/migration/application-builder', 'architecture/solana/migration/blockchain-api', - 'architecture/solana/migration/blockchain-etl', - 'architecture/solana/migration/blockchain-node', - 'architecture/solana/migration/console-operator', - 'architecture/solana/migration/exchange', - 'architecture/solana/migration/governance', - 'architecture/solana/migration/maker', 'architecture/solana/migration/hotspot-operator', - 'architecture/solana/migration/maker-hotspot-software', 'architecture/solana/migration/hst', 'architecture/solana/migration/ledger', - 'architecture/solana/migration/network-user', 'architecture/solana/migration/validator-operator', 'architecture/solana/migration/wallet-user', ], @@ -283,7 +272,6 @@ module.exports = { 'governance/governance', 'governance/voting', 'governance/governance-faq', - 'governance/realms', 'governance/vehnt', 'governance/staking-with-helium-vote', 'governance/working-groups', @@ -897,38 +885,6 @@ module.exports = { }, ], - // migration: [ - // { - // type: 'category', - // label: 'Solana Migration Overview', - // link: { type: 'doc', id: 'architecture/solana/migration-overview' }, - // items: [], - // collapsed: true, - // }, - // 'architecture/solana/migration-faq', - // 'architecture/solana/migration/hotspot-operator', - // 'architecture/solana/migration/validator-operator', - // { - // type: 'category', - // label: 'Hotspot Maker', - // items: [ - // 'architecture/solana/migration/maker', - // 'architecture/solana/migration/maker-hotspot-software', - // ], - // }, - // 'architecture/solana/migration/exchange', - // 'architecture/solana/migration/network-user', - // 'architecture/solana/migration/console-operator', - // 'architecture/solana/migration/application-builder', - // 'architecture/solana/migration/governance', - // 'architecture/solana/migration/blockchain-node', - // 'architecture/solana/migration/blockchain-api', - // 'architecture/solana/migration/blockchain-etl', - // 'architecture/solana/migration/wallet-user', - // 'architecture/solana/migration/ledger', - // 'architecture/solana/migration/hst', - // ], - console: [ { type: 'category', diff --git a/src/theme/RealmsPage.jsx b/src/theme/RealmsPage.jsx deleted file mode 100644 index 18e811a6b..000000000 --- a/src/theme/RealmsPage.jsx +++ /dev/null @@ -1,29 +0,0 @@ -import useBaseUrl from '@docusaurus/useBaseUrl' - -export const TestVoteImg = () => ( -
-
- - -
-
- The Helium DAO in Realms with an active - test vote. Shown on desktop and mobile. -
-
-) - -export const ConnectImg = () => ( -
- -
- This user is logged in with their 4qPt5... account. -
-
-) diff --git a/static/img/realms/availabletokens.png b/static/img/realms/availabletokens.png deleted file mode 100644 index 5472eb4bc..000000000 Binary files a/static/img/realms/availabletokens.png and /dev/null differ diff --git a/static/img/realms/castvote.png b/static/img/realms/castvote.png deleted file mode 100644 index bc44650e8..000000000 Binary files a/static/img/realms/castvote.png and /dev/null differ diff --git a/static/img/realms/cliffgraph.png b/static/img/realms/cliffgraph.png deleted file mode 100644 index 8f1c871c2..000000000 Binary files a/static/img/realms/cliffgraph.png and /dev/null differ diff --git a/static/img/realms/confirmvote.png b/static/img/realms/confirmvote.png deleted file mode 100644 index 168d54a41..000000000 Binary files a/static/img/realms/confirmvote.png and /dev/null differ diff --git a/static/img/realms/connectaccount.png b/static/img/realms/connectaccount.png deleted file mode 100644 index cc2eac334..000000000 Binary files a/static/img/realms/connectaccount.png and /dev/null differ diff --git a/static/img/realms/constantgraph.png b/static/img/realms/constantgraph.png deleted file mode 100644 index 99c0e98fb..000000000 Binary files a/static/img/realms/constantgraph.png and /dev/null differ diff --git a/static/img/realms/delegate.png b/static/img/realms/delegate.png deleted file mode 100644 index c098d9917..000000000 Binary files a/static/img/realms/delegate.png and /dev/null differ diff --git a/static/img/realms/duration.png b/static/img/realms/duration.png deleted file mode 100644 index d34700b53..000000000 Binary files a/static/img/realms/duration.png and /dev/null differ diff --git a/static/img/realms/issuestake.png b/static/img/realms/issuestake.png deleted file mode 100644 index 64a880cf0..000000000 Binary files a/static/img/realms/issuestake.png and /dev/null differ diff --git a/static/img/realms/landrush.png b/static/img/realms/landrush.png deleted file mode 100644 index 3a42b313a..000000000 Binary files a/static/img/realms/landrush.png and /dev/null differ diff --git a/static/img/realms/locktokensbtn.png b/static/img/realms/locktokensbtn.png deleted file mode 100644 index 6bf3e4761..000000000 Binary files a/static/img/realms/locktokensbtn.png and /dev/null differ diff --git a/static/img/realms/lockup.png b/static/img/realms/lockup.png deleted file mode 100644 index 18863df86..000000000 Binary files a/static/img/realms/lockup.png and /dev/null differ diff --git a/static/img/realms/lowbalanceerror.png b/static/img/realms/lowbalanceerror.png deleted file mode 100644 index 7b4ec98b1..000000000 Binary files a/static/img/realms/lowbalanceerror.png and /dev/null differ diff --git a/static/img/realms/multiplier.gif b/static/img/realms/multiplier.gif deleted file mode 100644 index 834f36542..000000000 Binary files a/static/img/realms/multiplier.gif and /dev/null differ diff --git a/static/img/realms/realmsbrowser.png b/static/img/realms/realmsbrowser.png deleted file mode 100644 index 6619bbb3b..000000000 Binary files a/static/img/realms/realmsbrowser.png and /dev/null differ diff --git a/static/img/realms/realmsui.png b/static/img/realms/realmsui.png deleted file mode 100644 index 47bfbe31a..000000000 Binary files a/static/img/realms/realmsui.png and /dev/null differ diff --git a/static/img/realms/realmsui_mobile.png b/static/img/realms/realmsui_mobile.png deleted file mode 100644 index acd13a729..000000000 Binary files a/static/img/realms/realmsui_mobile.png and /dev/null differ diff --git a/static/img/realms/relinquishvote.png b/static/img/realms/relinquishvote.png deleted file mode 100644 index 8d8811ecc..000000000 Binary files a/static/img/realms/relinquishvote.png and /dev/null differ diff --git a/static/img/realms/stakewlockup.png b/static/img/realms/stakewlockup.png deleted file mode 100644 index 63681d062..000000000 Binary files a/static/img/realms/stakewlockup.png and /dev/null differ diff --git a/static/img/realms/transfer.png b/static/img/realms/transfer.png deleted file mode 100644 index 3f4a7527b..000000000 Binary files a/static/img/realms/transfer.png and /dev/null differ diff --git a/static/img/realms/validatorstake.png b/static/img/realms/validatorstake.png deleted file mode 100644 index a11d38aef..000000000 Binary files a/static/img/realms/validatorstake.png and /dev/null differ