Update security email

CHANGELOG.md

@@ -39,6 +39,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 
 ### Improvements
 
+- [#464](https://github.com/babylonlabs-io/babylon/pull/464) Update security email. Fix site / repository refs
 - [#421](https://github.com/babylonlabs-io/babylon/pull/421) Add checks to public
 randomness commit at `TestBTCRewardsDistribution`.
 - [#391](https://github.com/babylonlabs-io/babylon/pull/391) Fix e2e `TestBTCRewardsDistribution` flunky

README.md

@@ -8,7 +8,7 @@ Unlocking 21 Million ₿ to Secure the Decentralized Economy
 [![Medium](https://badgen.net/badge/icon/medium?icon=medium&label)](https://medium.com/babylonlabs-io)
 
 [Babylon](https://babylonlabs.io) provides a suite of security-sharing
-protocols between Bitcoin and the PoS world. It provides two inter-connected
+protocols between Bitcoin and the PoS world. It provides two interconnected
 protocols:
 
 - **Bitcoin timestamping:** Submits succinct and verifiable timestamps of any

SECURITY.md

@@ -21,7 +21,7 @@ To privately report a security vulnerability, please choose one of the following
 
 ### 1. Email
 
-Send your detailed vulnerability report to `security@babylonchain.io`.
+Send your detailed vulnerability report to `security@babylonlabs.io`.
 
 ### 2. GitHub Private Vulnerability Reporting
 
@@ -79,4 +79,4 @@ place.
 
 ## Feedback on this Policy
 
-For recommendations on how to improve this policy, either submit a pull request or email `security@babylonchain.io`.
+For recommendations on how to improve this policy, either submit a pull request or email `security@babylonlabs.io`.

docs/architecture.md

@@ -82,7 +82,7 @@ voting power is cast on it.
 The voting power of each finality provider is based on
 its Bitcoin stake retrieved from the BTC Staking module.
 Finality votes are performed using
-[Extractable-One-Time-Signatures (EOTS)](https://docs.babylonchain.io/assets/files/btc_staking_litepaper-32bfea0c243773f0bfac63e148387aef.pdf)
+[Extractable-One-Time-Signatures (EOTS)](https://docs.babylonlabs.io/assets/files/btc_staking_litepaper-32bfea0c243773f0bfac63e148387aef.pdf)
 and verified using
 the finality providers' committed public randomness.
 
@@ -103,14 +103,14 @@ operator of each of the programs exist.
 Otherwise,
 an alarm will be raised by the monitor program.
 
-### [Vigilante Submitter](https://github.com/babylonchain/vigilante)
+### [Vigilante Submitter](https://github.com/babylonlabs-io/vigilante)
 
 A standalone program that submits
 Babylon checkpoints to Bitcoin as
 Bitcoin transactions embedding data
 utilizing the `OP_RETURN` Bitcoin script code.
 
-### [Vigilante Reporter](https://github.com/babylonchain/vigilante)
+### [Vigilante Reporter](https://github.com/babylonlabs-io/vigilante)
 
 A standalone program that scans
 the Bitcoin ledger for Bitcoin headers and Babylon checkpoints,
@@ -122,7 +122,7 @@ The monitor programs suite is responsible for
 monitoring the consistency between Babylon's state and
 Bitcoin.
 
-### [Checkpointing Monitor](https://github.com/babylonchain/vigilante)
+### [Checkpointing Monitor](https://github.com/babylonlabs-io/vigilante)
 
 A standalone program that monitors:
 
@@ -132,7 +132,7 @@ A standalone program that monitors:
 - The timely inclusion of Babylon's Bitcoin checkpoints
   information in the Babylon ledger.
 
-### [BTC Staking Monitor](https://github.com/babylonchain/vigilante)
+### [BTC Staking Monitor](https://github.com/babylonlabs-io/vigilante)
 
 A standalone program that monitors:
 
@@ -165,27 +165,27 @@ withdraw their funds when their stake expires.
 The following set of standalone programs
 has been developed to enable these functionalities:
 
-- [BTC Staker Daemon](https://github.com/babylonchain/btc-staker):
+- [BTC Staker Daemon](https://github.com/babylonlabs-io/btc-staker):
   Daemon program connecting to a Bitcoin wallet and Babylon.
-- [BTC Staker Dashboard](https://github.com/babylonchain/btc-staking-dashboard):
+- [BTC Staker Dashboard](https://github.com/babylonlabs-io/btc-staking-dashboard):
   Web application connecting to a Bitcoin wallet extension and the Babylon API.
   It should only be used for testing purposes.
 - Wallet Integrations (TBD)
 
-### [Finality Provider](https://github.com/babylonchain/finality-provider)
+### [Finality Provider](https://github.com/babylonlabs-io/finality-provider)
 
 A standalone program that allows the registration and
 maintenance of a finality provider.
 It monitors for a finality provider's inclusion in the active set, commits
-[Extractable One Time Signature (EOTS)](https://docs.babylonchain.io/assets/files/btc_staking_litepaper-32bfea0c243773f0bfac63e148387aef.pdf)
+[Extractable One Time Signature (EOTS)](https://docs.babylonlabs.io/assets/files/btc_staking_litepaper-32bfea0c243773f0bfac63e148387aef.pdf)
 public randomness, and
 submits finality votes for blocks.
 Finality votes are created through a connection to a standalone
-[EOTS manager daemon](https://github.com/babylonchain/finality-provider)
+[EOTS manager daemon](https://github.com/babylonlabs-io/finality-provider)
 responsible for securely maintaining the
 finality provider's private keys.
 
-### [Covenant Emulator](https://github.com/babylonchain/covenant-emulator)
+### [Covenant Emulator](https://github.com/babylonlabs-io/covenant-emulator)
 
 A standalone program utilized by the covenant emulation committee members.
 It emulates [covenant](https://covenants.info) functionality by monitoring

docs/transaction-impl-spec.md

@@ -26,7 +26,7 @@ account before propagating a transaction to Bitcoin.
 For the rest of the document, we will refer to those parameters as `global_parameters`.
 
 More details about parameters can be found in the
-[parameters spec](https://github.com/babylonchain/networks/tree/main/bbn-test-4/parameters).
+[latest testnet docs](https://github.com/babylonlabs-io/networks/tree/main/bbn-test-5/).
 
 ## Taproot outputs
 

wasmbinding/testdata/Cargo.toml

@@ -8,4 +8,4 @@ edition = "2021"
 crate-type = ["cdylib", "rlib"]
 
 [dependencies]
-babylon-example = { git = "https://github.com/babylonchain/bindings", tag = "v0.1.0" }
+babylon-example = { git = "https://github.com/babylonlabs-io/bindings", tag = "v0.1.0" }

wasmbinding/testdata/README.md

@@ -1,7 +1,7 @@
 # Stub test contract
 
 This folder contains bogus test contract which just exposes public api from
-example contract from babylon bindings repo - https://github.com/babylonchain/bindings/tree/main/contracts/example
+example contract from babylon bindings repo - https://github.com/babylonlabs-io/bindings/tree/main/contracts/example
 
 This approach enables us to specify which branch from bindings library we want to test/use.
 

x/btccheckpoint/README.md

@@ -29,13 +29,13 @@ Babylon's BTC Checkpoint module allows Babylon chain to periodically checkpoint
 
 Checkpoint Submission:
 1. When a new checkpoint for a specific epoch is available, the [vigilante](https://github.com/babylonlabs-io/vigilante) collects the necessary proof from the Bitcoin blockchain and submits raw transactions containing the checkpoint to the Babylon chain.
-2. This proof is called an `SPVProof` (Simplified Payment Verification Proof), consisting of the Bitcoin transaction, Index of the transaction, the Merkle path and the Bitcoin header that confirms the transaction.
-3. The [vigilante reporter](https://github.com/babylonlabs-io/vigilante/blob/47956edbb72112162e4cecca5b9d1e0ad840dd47/reporter/utils.go#L191) submits this proof to the Babylon chain using the `InsertBTCSpvProof` function. The proof is validated and stored in state. This includes parsing the submission, checking for duplicates, and verifying the checkpoint with the [checkpointing module](https://github.com/babylonlabs-io/babylon/blob/main/x/checkpointing/README.md).
+2. This proof is called an `SPVProof` (Simplified Payment Verification Proof), consisting of the Bitcoin transaction, Index of the transaction, the Merkle path and the Bitcoin header that confirms the transaction.
+3. The [vigilante reporter](https://github.com/babylonlabs-io/vigilante/blob/47956edbb72112162e4cecca5b9d1e0ad840dd47/reporter/utils.go#L191) submits this proof to the Babylon chain using the `InsertBTCSpvProof` function. The proof is validated and stored in state. This includes parsing the submission, checking for duplicates, and verifying the checkpoint with the [checkpointing module](https://github.com/babylonlabs-io/babylon/blob/main/x/checkpointing/README.md).
 
 Checkpoint Verification:
-1. The Babylon chain maintains a Bitcoin light client through the [BTC Light Client module](https://github.com/babylonchain/babylon/blob/dev/x/btclightclient/README.md). This module is responsible for tracking Bitcoin block headers, allowing Babylon to verify the depth and validity of Bitcoin transactions without running a full Bitcoin node.
-2. When new Bitcoin blocks are produced, the headers are relayed to and processed by the Babylon chain's light client.
-3. As the light client's tip changes, it triggers the `OnTipChange` callback.
+1. The Babylon chain maintains a Bitcoin light client through the [BTC Light Client module](https://github.com/babylonlabs-io/babylon/blob/dev/x/btclightclient/README.md). This module is responsible for tracking Bitcoin block headers, allowing Babylon to verify the depth and validity of Bitcoin transactions without running a full Bitcoin node.
+2. When new Bitcoin blocks are produced, the headers are relayed to and processed by the Babylon chain's light client.
+3. As the light client's tip changes, it triggers the `OnTipChange` callback.
 4. This callback initiates the `checkCheckpoints` process, which verifies the status of all submitted checkpoints based on their confirmation depth in the Bitcoin blockchain. This process includes:
 
    * Checking if the checkpoint is still on the canonical chain
@@ -68,7 +68,7 @@ The BTC Checkpoint module uses a combination of prefixed namespaces and individu
 - `ParamsKey` stores modules parameters.
 
 ### Parameters
-The [parameter management](https://github.com/babylonlabs-io/babylon/blob/main/x/btccheckpoint/keeper/params.go) maintains the BTC Checkpoint module's parameters. The BTC Checkpoint module's parameters are represented as a `Params` [object](https://github.com/babylonlabs-io/babylon/blob/main/proto/babylon/btccheckpoint/v1/params.proto) defined as follows:
+The [parameter management](https://github.com/babylonlabs-io/babylon/blob/main/x/btccheckpoint/keeper/params.go) maintains the BTC Checkpoint module's parameters. The BTC Checkpoint module's parameters are represented as a `Params` [object](https://github.com/babylonlabs-io/babylon/blob/main/proto/babylon/btccheckpoint/v1/params.proto) defined as follows:
 
 ```protobuf
 // Params defines the parameters for the module.
@@ -99,7 +99,7 @@ message Params {
 
 ### Epoch Data
 
-Epoch data is managed by [submissions management](https://github.com/babylonlabs-io/babylon/blob/main/x/btccheckpoint/keeper/submissions.go) and is used to store and retrieve epoch-related data. The epoch data is indexed by epoch number and is represented as an `EpochData` object:
+Epoch data is managed by [submissions management](https://github.com/babylonlabs-io/babylon/blob/main/x/btccheckpoint/keeper/submissions.go) and is used to store and retrieve epoch-related data. The epoch data is indexed by epoch number and is represented as an `EpochData` object:
 
 ```protobuf
 message EpochData {
@@ -114,11 +114,11 @@ message EpochData {
 
 ### Latest Finalized Epoch
 
-The Last Finalized Epoch number is stored in the state as a big-endian encoded uint64 value. It's accessed and modified using specific getter and setter functions in the keeper.
+The Last Finalized Epoch number is stored in the state as a big-endian encoded uint64 value. It's accessed and modified using specific getter and setter functions in the keeper.
 
 ### Submission Data
 
-The [submissions management](https://github.com/babylonlabs-io/babylon/blob/main/x/btccheckpoint/keeper/submissions.go) is responsible for managing and interacting with checkpoint submissions in the BTC checkpoint module The `SubmissionData` is defined as an object below.
+The [submissions management](https://github.com/babylonlabs-io/babylon/blob/main/x/btccheckpoint/keeper/submissions.go) is responsible for managing and interacting with checkpoint submissions in the BTC checkpoint module The `SubmissionData` is defined as an object below.
 
 ```protobuf
 message SubmissionData {
@@ -138,7 +138,7 @@ message SubmissionData {
 
 ### BTC Light Client Update
 
-The BTC Light Client Update is maintained in the transient store during block execution. It is accessed using the `BtcLightClientUpdatedKey` and indicates whether the BTC light client was updated during the current block execution.
+The BTC Light Client Update is maintained in the transient store during block execution. It is accessed using the `BtcLightClientUpdatedKey` and indicates whether the BTC light client was updated during the current block execution.
 
 ```go
 func GetBtcLightClientUpdatedKey() []byte {
@@ -155,21 +155,21 @@ The BTC Checkpoint module primarily handles messages from the vigilante reporter
 `MsgInsertBTCSpvProof` is used by vigilante reporter to insert a new checkpoint into the store, which can be seen [here](https://github.com/babylonlabs-io/vigilante/blob/24da0381465249aa7b55be682a66e32cdaddc81b/types/btccheckpoint.go#L11). 
 
 ```protobuf
-message MsgInsertBTCSpvProof {
-  option (cosmos.msg.v1.signer) = "submitter";
-  string submitter = 1;
-  repeated babylon.btccheckpoint.v1.BTCSpvProof proofs = 2;
+message MsgInsertBTCSpvProof {
+  option (cosmos.msg.v1.signer) = "submitter";
+  string submitter = 1;
+  repeated babylon.btccheckpoint.v1.BTCSpvProof proofs = 2;
 }
 ```
 
 Upon receiving a `MsgInsertBTCSpvProof`, a Babylon node will execute as follows:
 
 1. Parse and validate the raw checkpoint data from the proof.
 2. Create a new `RawCheckpointSubmission` object from the parsed data.
-3. Verify if the submission is for the expected checkpoint by calling the checkpointing keeper.
-4. Check if the checkpoint is valid for the current epoch.
+3. Verify if the submission is for the expected checkpoint by calling the checkpointing keeper.
+4. Check if the checkpoint is valid for the current epoch.
 5. Verify the ancestors of the checkpoint to ensure continuity.
-6. If all verifications pass, the new checkpoint submission is stored and the checkpoint status is updated.
+6. If all verifications pass, the new checkpoint submission is stored and the checkpoint status is updated.
 
 ## MsgUpdateParams
 
@@ -201,24 +201,24 @@ The logic for the `EndBlocker` is defined in at [x/btccheckpoint/abci.go](https:
 
 ## Queries
 
-The BTC Checkpoint module provides a set of queries related to the status of checkpoints and other checkpoint-related data. These queries can be accessed via gRPC and REST endpoints.
+The BTC Checkpoint module provides a set of queries related to the status of checkpoints and other checkpoint-related data. These queries can be accessed via gRPC and REST endpoints.
 
 ### Available Queries
 
 **Parameters**\
-Endpoint: `/babylon/btccheckpoint/v1/params`\
+Endpoint: `/babylon/btccheckpoint/v1/params`\
 Description: Queries the current parameters of the BTC Checkpoint module.
 
 **BTC Checkpoint Info**\
-Endpoint: `/babylon/btccheckpoint/v1/{epoch_num}`\
+Endpoint: `/babylon/btccheckpoint/v1/{epoch_num}`\
 Description: Retrieves the best checkpoint information for a given epoch.
 
 **BTC Checkpoints Info**\
-Endpoint: `/babylon/btccheckpoint/v1/`\
+Endpoint: `/babylon/btccheckpoint/v1/`\
 Description: Retrieves checkpoint information for multiple epochs with pagination support.
 
 **Epoch Submissions**\
-Endpoint: `/babylon/btccheckpoint/v1/{epoch_num}/submissions`\
+Endpoint: `/babylon/btccheckpoint/v1/{epoch_num}/submissions`\
 Description: Retrieves all submissions for a given epoch.
 
-Additional Information: For further details on how to use these queries and additional documentation, please refer to docs.babylonchain.io.
+Additional Information: For further details on how to use these queries and additional documentation, please refer to docs.babylonlabs.io.