remove v2 suffix when not needed

Author: marcello33

docs/pos/architecture/heimdall_v2/balance-transfers.md

@@ -15,9 +15,9 @@ interaction with other modules which must alter user balances.
 In addition, the bank module tracks and provides query support for the total
 supply of all assets used in the application.
 
-This module is used in the Cosmos Hub and [Heimdall-v2](https://github.com/0xPolygon/heimdall-v2).
+This module is used in the Cosmos Hub and [Heimdall](https://github.com/0xPolygon/heimdall-v2).
 
-**NOTE**: For heimdall-v2, minimal changes have been done in the fork listed [here](#conceptschanges-specific-to-heimdall-v2)
+**NOTE**: For heimdall, minimal changes have been done in the fork listed [here](#conceptschanges-specific-to-heimdall)
 
 ## Supply
 
@@ -1016,12 +1016,12 @@ Example Output:
 }
 ```
 
-## concepts/changes specific to heimdall-v2
+## concepts/changes specific to heimdall
 
 Since heimdall is a unique component of the PoS architecture and not a traditional Cosmos SDK app, some changes had to be made in order to ensure correct functionality, some of which are :
 
 * MsgSetSendEnabled is not supported since POL is the only denom used. 
 
 * (Un)delegation is not supported since staking related logic is handled by PoS [core contracts](https://github.com/0xPolygon/core-contracts/tree/main/contracts) deployed on Ethereum.
 
-* A default fee of 10^15 POL (`DefaultFeeInPol`) is deducted from the tx sender.
+* A default fee of 10^15 POL (`DefaultFeeInPol`) is deducted from the tx sender.

docs/pos/architecture/heimdall_v2/changes-from-v1.md

@@ -1,6 +1,6 @@
 
 
-# Heimdall v2 changes compared to v1
+# Heimdall-v2 changes compared to v1
 
 There are a number of differences between Heimdall v1 to v2. These changes are outlined below:
 
@@ -13,7 +13,7 @@ Hex encoded: `BJSk2KCI4snP2Cw/ntDdgp8R25XJ2xg18KL67fyEAwgtPMpeq5APSUHrkv5wtgrFfp
 Base64 encoded: `0x0494a4d8a088e2c9cfd82c3f9ed0dd829f11db95c9db1835f0a2faedfc8403082d3cca5eab900f4941eb92fe70b60ac57e999c0e2be73fc1cf1ae7f2c979c1cb1a`
 
 ## Validator signing key
-In Heimdall v2, validator signing keys must be imported into the keyring for transaction signing. For details of keyring, refer to the Cosmos SDK documentation [here](https://docs.cosmos.network/v0.46/run-node/keyring.html)
+In Heimdall-v2, validator signing keys must be imported into the keyring for transaction signing. For details of keyring, refer to the Cosmos SDK documentation [here](https://docs.cosmos.network/v0.46/run-node/keyring.html)
 
 From the Cosmos documentation:
 
@@ -42,4 +42,4 @@ When running a `tx` command, just specify the `--from` argument, by using the na
 
 ## Vote extension in each block
 
-In Heimdall v2, the first transaction of each block will contain the encoded vote extensions. To decode these, use the additional command in `heimdallld`
+In Heimdall-v2, the first transaction of each block will contain the encoded vote extensions. To decode these, use the additional command in `heimdallld`

docs/pos/architecture/heimdall_v2/checkpoints.md

@@ -56,7 +56,7 @@ Additionally, the selection of the next checkpoint proposer is adjusted based on
 The `MsgCpNoAck` message is broadcast by the bridge processor to indicate that a checkpoint was potentially transferred to the Ethereum chain but has not received an acknowledgment.  
 A background routine periodically checks for time elapsed and publishes the No-ACK signal. No-ACK is sent if a sufficient amount of time has passed since:
 
-- the last checkpoint was created on the Heimdall v2 chain and
+- the last checkpoint was created on the Heimdall-v2 chain and
 - the last No-ACK was issued.  
   To conclude, the No-ACKs are triggered only when a checkpoint acknowledgment is overdue, ensuring they are not sent too frequently.  
   This message is broadcasted only by the proposer. This entire flow ensures that checkpoints are securely proposed, verified, and finalized across the Heimdall and Ethereum chains in a decentralized manner.

docs/pos/architecture/heimdall_v2/introduction.md

@@ -1,6 +1,6 @@
-# Heimdall v2
+# Heimdall-v2
 
-Heimdall v2 is a modernized and revamped consensus client that is at the heart of the Polygon PoS network. Similar to the previous version of Heimdall it performs the following functions:
+Heimdall-v2 is a modernized and revamped consensus client that is at the heart of the Polygon PoS network. Similar to the previous version of Heimdall it performs the following functions:
 
 - Manages validators.
 - Handles block producer selection.
@@ -12,4 +12,4 @@ It uses a fork of [*Cosmos SDK*](https://github.com/0xPolygon/cosmos-sdk) based
 
 Heimdall leverages some modified versions of `cosmos-sdk` modules (`auth`, `bank` and `gov`) plus some fully customized modules (`bor`, `chainmanager`, `checkpoint`, `clerk`, `milestone`, `stake` and `topup`).
 
-For detailed instructions on running Heimdall v2, refer to the [Readme](https://github.com/0xPolygon/heimdall-v2/blob/develop/README.md) in the Github repository
+For detailed instructions on running Heimdall, refer to the [Readme](https://github.com/0xPolygon/heimdall-v2/blob/develop/README.md) in the Github repository

docs/pos/architecture/heimdall_v2/staking.md

@@ -12,7 +12,7 @@ this module saves the validator information on Heimdall state.
 
 ## Flow
 
-The x/stake module manages validator-related transactions and validator set management for Heimdall v2.
+The x/stake module manages validator-related transactions and validator set management for Heimdall.
 
 Validators stake their tokens on the Ethereum chain to participate in consensus. To synchronize these changes with Heimdall, the bridge processor broadcasts the corresponding transaction for an Ethereum-emitted event, choosing from one of the following messages each with the necessary parameters:
 
@@ -21,14 +21,14 @@ Validators stake their tokens on the Ethereum chain to participate in consensus.
 - `MsgValidatorExit`: When a validator decides to exit, they initiate the process on Ethereum, leading to the emission of a `UnstakeInit` event. This message ensures that Heimdall records the validator’s departure accordingly.  
 - `MsgSignerUpdate`: This message is responsible for processing changes to a validator’s signer key. When a validator updates their signer key on Ethereum, it emits a `SignerUpdate` event, prompting Heimdall to reflect the new signer key in its records.
 
-Each of these transactions in Heimdall v2 follows the same processing mechanisms, leveraging ABCI++ phases.
+Each of these transactions in Heimdall follows the same processing mechanisms, leveraging ABCI++ phases.
 
 During the `PreCommit` phase, side transaction handlers are triggered, and a vote is injected after validating the Ethereum-emitted event and ensuring its alignment with the data in the processed message.
 
 Once a majority of validators confirm that the action described in the message has occurred on Ethereum, the x/stake module updates the validator’s state in Heimdall during the `FinalizeBlock`’s `PreBlocker` execution.  
 
 ### Replay Prevention Mechanism
-Heimdall v2 employs a replay prevention mechanism in the post-tx handler functions to ensure that validator update messages derived from Ethereum events are not processed multiple times.
+Heimdall employs a replay prevention mechanism in the post-tx handler functions to ensure that validator update messages derived from Ethereum events are not processed multiple times.
 
 This mechanism prevents replay attacks by assigning a unique sequence number to each transaction and verifying whether it has already been processed.  
 The sequence number is constructed using the Ethereum block number and log index, following the formula:
@@ -294,4 +294,4 @@ curl localhost:1317/stake/is-old-tx?tx_hash=<tx-hash>&log_index=<log-index>
 
 ```bash
 curl localhost:1317/stake/proposers/{times}
-```
+```

docs/pos/architecture/heimdall_v2/topup.md

@@ -13,7 +13,7 @@ There are two ways to top up your account:
 
 ## Flow
 
-The Heimdall Top-up Mechanism facilitates the management of validator fees on the Heimdall v2 chain by allowing deposits from the Ethereum (L1) root chain.  
+The Heimdall Top-up Mechanism facilitates the management of validator fees on the Heimdall chain by allowing deposits from the Ethereum (L1) root chain.  
 This mechanism ensures validators have enough balances on Heimdall to cover operational fees.  
 The system integrates staking smart contract on Ethereum with Heimdall custom x/topup and x/checkpoint modules and a bridge component to enable seamless cross-chain fee management.  
 
@@ -47,7 +47,7 @@ Each top-up is uniquely identified by a sequence number built from `TxHash` and
 `MsgTopupTx` is a side-transaction, ensuring state changes only after the successful pre-commit majority of the votes are collected and final validation and post-tx handler execution in the following block height.  
 When broadcasting the `MsgTopupTx` - sender (proposer of the topup) must sign it, and additional user address must be sent.
 
-For the top-up to be accepted, the `MsgTopupTx.Fee` must be at least equal to the `DefaultFeeWantedPerTx` amount. The top-up processing on Heimdall v2 involves:
+For the top-up to be accepted, the `MsgTopupTx.Fee` must be at least equal to the `DefaultFeeWantedPerTx` amount. The top-up processing on Heimdall involves:
 
 - Minting the top-up number of pol tokens to the top-up module account.  
 - Transferring the entire amount from the top-up module account to the user account.  
@@ -227,4 +227,4 @@ curl localhost:1317/topup/account-proof/{address}/verify
 
 ```bash
 curl localhost:1317/topup/account-proof/{address}
-```
+```

docs/pos/architecture/overview.md

@@ -54,13 +54,13 @@ An overview of the process:
 * A selected proposer from the validator set is responsible for collecting all signatures for a particular checkpoint and committing the checkpoint on the Ethereum mainnet.
 * The responsibility of creating blocks and proposing checkpoints is variably dependent on a validator’s stake ratio in the overall pool.
 
-Heimdall (v1) was deprecated and replaced by Heimdall-v2.  
+The original Heimdall implementation (v1) was deprecated and replaced by Heimdall-v2.  
 In these docs, referring to Heimdall means Heimdall-v2, unless otherwise specified.  
 The new version is a complete rewrite of the original Heimdall, based on Cosmos SDK and CometBFT.  
 More information can be found in the following PIPs:
 - [PIP-43: Replacing Tendermint with CometBFT](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/cb371136414b5e198c44750cd4c30f7aad16043a/PIPs/PIP-43.md)
 - [PIP-44: Upgrade Cosmos-SDK](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/cb371136414b5e198c44750cd4c30f7aad16043a/PIPs/PIP-44.md)
-- [PIP-62: Heimdall v2 Migration](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/cb371136414b5e198c44750cd4c30f7aad16043a/PIPs/PIP-62.md)
+- [PIP-62: Heimdall-v2 Migration](https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/cb371136414b5e198c44750cd4c30f7aad16043a/PIPs/PIP-62.md)
 
 ## Bor: Block production layer
 

docs/pos/governance/governance-fundamentals.md

@@ -39,7 +39,7 @@ The framework is composed of three key components:
 
 The PoS network currently uses two clients simultaneously:
 
-- Heimdall-v2: The [consensus layer](https://docs.polygon.technology/pos/architecture/heimdall_v2/introduction/) - [See GitHub](https://github.com/0xPolygon/heimdall-v2)
+- Heimdall: The [consensus layer](https://docs.polygon.technology/pos/architecture/heimdall_v2/introduction/) - [See GitHub](https://github.com/0xPolygon/heimdall-v2)
 - Bor: The [execution layer](https://docs.polygon.technology/pos/architecture/bor/introduction/) client - [See GitHub](https://github.com/0xPolygon/bor)
 
 Currently, Bor and Heimdall are the majority clients for the PoS network. These clients serve as ecosystem focal points rather than control switches operated by core developers that can dictate decisions.

docs/pos/how-to/full-node/full-node-binaries.md

@@ -44,12 +44,12 @@ Both binaries must be installed and run in the correct order to function properl
 
 ### Heimdall
 
-Install the latest version of Heimdall-v2 and related services. Make sure you checkout to the correct [release version](https://github.com/0xPolygon/heimdall-v2/releases).
+Install the latest version of Heimdall and related services. Make sure you checkout to the correct [release version](https://github.com/0xPolygon/heimdall-v2/releases).
 
-To install *Heimdall-v2*, run the following commands:
+To install *Heimdall*, run the following commands:
 
 ```bash
-curl -L https://raw.githubusercontent.com/0xPolygon/install/main/heimdall-v2.sh | bash -s -- <heimdall_version> <network> <node_type>
+curl -L https://raw.githubusercontent.com/0xPolygon/install/heimdall-v2/heimdall-v2.sh | bash -s -- <heimdall_version> <network> <node_type>
 ```
 
 You can run the above command with the following options:
@@ -74,13 +74,13 @@ Where `BUCKET_URL` is
 - https://storage.googleapis.com/amoy-heimdallv2-genesis/migrated_dump-genesis.json for amoy
 - https://storage.googleapis.com/mainnet-heimdallv2-genesis/migrated_dump-genesis.json for mainnet
 
-Verify the installation by checking the Heimdall-v2 version on your machine:
+Verify the installation by checking the Heimdall version on your machine:
 
 ```bash
 heimdalld version
 ```
 
-It should return the version of Heimdall-v2 you installed.  
+It should return the version of Heimdall you installed.  
 
 ### Bor
 
@@ -101,7 +101,7 @@ That will install the `bor` binary. Verify the installation by checking the Bor
 bor version
 ```
 
-### Configure Heimdall-v2 and Bor seeds
+### Configure Heimdall and Bor seeds
 
 The latest bor and heimdall seeds can be found [here](https://docs.polygon.technology/pos/reference/seed-and-bootnodes/). To configure them, update the following lines:
 
@@ -130,7 +130,7 @@ sed -i 's/User=bor/User=root/g' /lib/systemd/system/bor.service
 
 ## Start services
 
-Run the full Heimdall-v2 node with these commands on your Sentry Node:
+Run the full Heimdall node with these commands on your Sentry Node:
 
 ```bash
 sudo service heimdalld start

docs/pos/how-to/full-node/full-node-docker.md

@@ -136,7 +136,7 @@ curl -L -o "<HEIMDALL_HOME>/config/genesis.json" <BUCKET_URL>
 
 where `BUCKET_URL` is https://storage.googleapis.com/amoy-heimdallv2-genesis/migrated_dump-genesis.json for amoyand https://storage.googleapis.com/mainnet-heimdallv2-genesis/migrated_dump-genesis.json for mainnet
 
-Replace `HEIMDALL_HOME` with the actual path to your Heimdall-v2 home directory.
+Replace `HEIMDALL_HOME` with the actual path to your Heimdall home directory.
 
 Please note that the genesis file size is around 50MB for amoy and 3GB for mainnet.  
 Hence, the download might take a while, and it’s recommended to use a stable and fast connection.