diff --git a/CHANGELOG.md b/CHANGELOG.md index 2ef9e2bd2..f66132d61 100644 --- a/CHANGELOG.md +++ b/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 diff --git a/README.md b/README.md index 358c86750..ceccc51f9 100644 --- a/README.md +++ b/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 diff --git a/SECURITY.md b/SECURITY.md index ee8c3febf..7f9848083 100644 --- a/SECURITY.md +++ b/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`. diff --git a/docs/architecture.md b/docs/architecture.md index 6b40869fd..2d5f7db96 100644 --- a/docs/architecture.md +++ b/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 diff --git a/docs/transaction-impl-spec.md b/docs/transaction-impl-spec.md index 9cbbe546c..9fa827126 100644 --- a/docs/transaction-impl-spec.md +++ b/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 diff --git a/wasmbinding/testdata/Cargo.lock b/wasmbinding/testdata/Cargo.lock index 920856fc1..bf7b726f0 100644 --- a/wasmbinding/testdata/Cargo.lock +++ b/wasmbinding/testdata/Cargo.lock @@ -1,6 +1,6 @@ # This file is automatically @generated by Cargo. # It is not intended for manual editing. -version = 3 +version = 4 [[package]] name = "ahash" @@ -16,7 +16,7 @@ dependencies = [ [[package]] name = "babylon-bindings" version = "0.1.0" -source = "git+https://github.com/babylonchain/bindings?tag=v0.1.0#7c209ab2cd289b9bad57958d5bc074cb8ded5a5c" +source = "git+https://github.com/babylonlabs-io/bindings?tag=v0.1.0#7c209ab2cd289b9bad57958d5bc074cb8ded5a5c" dependencies = [ "cosmwasm-schema", "cosmwasm-std", @@ -27,7 +27,7 @@ dependencies = [ [[package]] name = "babylon-example" version = "0.1.0" -source = "git+https://github.com/babylonchain/bindings?tag=v0.1.0#7c209ab2cd289b9bad57958d5bc074cb8ded5a5c" +source = "git+https://github.com/babylonlabs-io/bindings?tag=v0.1.0#7c209ab2cd289b9bad57958d5bc074cb8ded5a5c" dependencies = [ "babylon-bindings", "cosmwasm-schema", diff --git a/wasmbinding/testdata/Cargo.toml b/wasmbinding/testdata/Cargo.toml index bfc90296f..8d049ba3c 100644 --- a/wasmbinding/testdata/Cargo.toml +++ b/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" } diff --git a/wasmbinding/testdata/README.md b/wasmbinding/testdata/README.md index 200456134..4ad5c96c7 100644 --- a/wasmbinding/testdata/README.md +++ b/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. diff --git a/x/btccheckpoint/README.md b/x/btccheckpoint/README.md index 8e97e4606..2bf88af65 100644 --- a/x/btccheckpoint/README.md +++ b/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,10 +155,10 @@ 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; } ``` @@ -166,10 +166,10 @@ 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. \ No newline at end of file +Additional Information: For further details on how to use these queries and additional documentation, please refer to docs.babylonlabs.io. \ No newline at end of file diff --git a/x/btcstaking/README.md b/x/btcstaking/README.md index 416241299..236681d44 100644 --- a/x/btcstaking/README.md +++ b/x/btcstaking/README.md @@ -140,7 +140,7 @@ delegations under culpable finality providers. A BTC staker can unbond early by signing the unbonding transaction and submitting it to Bitcoin. The BTC Staking module identifies unbonding requests through this signature reported by the [BTC staking tracker -daemon](https://github.com/babylonchain/vigilante), and will consider the BTC +daemon](https://github.com/babylonlabs-io/vigilante), and will consider the BTC delegation unbonded immediately upon such a signature. ## States @@ -378,7 +378,7 @@ The message handlers are defined at The `MsgCreateFinalityProvider` message is used for creating a finality provider. It is typically submitted by a finality provider via the [finality -provider](https://github.com/babylonchain/finality-provider) program. +provider](https://github.com/babylonlabs-io/finality-provider) program. ```protobuf // MsgCreateFinalityProvider is the message for creating a finality provider @@ -475,7 +475,7 @@ Upon `MsgEditFinalityProvider`, a Babylon node will execute as follows: The `MsgCreateBTCDelegation` message is used for delegating some bitcoin to a finality provider. It is typically submitted by a BTC delegator via the [BTC -staker](https://github.com/babylonchain/btc-staker) program. +staker](https://github.com/babylonlabs-io/btc-staker) program. ```protobuf // MsgCreateBTCDelegation is the message for creating a BTC delegation @@ -610,7 +610,7 @@ node will execute as follows: The `MsgAddCovenantSigs` message is used for submitting signatures on a BTC delegation signed by a covenant committee member. It is typically submitted by a covenant committee member via the [covenant -emulator](https://github.com/babylonchain/covenant-emulator) program. +emulator](https://github.com/babylonlabs-io/covenant-emulator) program. ```protobuf // MsgAddCovenantSigs is the message for handling signatures from a covenant member @@ -655,7 +655,7 @@ Upon `AddCovenantSigs`, a Babylon node will execute as follows: The `MsgBTCUndelegate` message is used for unbonding bitcoin from a given finality provider. It is typically reported by the [BTC staking -tracker](https://github.com/babylonchain/vigilante/tree/dev/btcstaking-tracker) +tracker](https://github.com/babylonlabs-io/vigilante/tree/main/btcstaking-tracker) program which proactively monitors unbonding transactions on Bitcoin. ```protobuf @@ -751,7 +751,7 @@ Upon `MsgSelectiveSlashingEvidence`, a Babylon node will execute as follows: this. The `MsgSelectiveSlashingEvidence` is typically reported by the [BTC staking -tracker](https://github.com/babylonchain/vigilante/tree/dev/btcstaking-tracker) +tracker](https://github.com/babylonlabs-io/vigilante/tree/main/btcstaking-tracker) program. It keeps monitoring for slashing transactions on Bitcoin. Upon each slashing transaction, it will try to extract the finality provider's secret key. If successful, it will construct a `MsgSelectiveSlashingEvidence` message and @@ -977,6 +977,6 @@ Endpoint: `/babylon/btcstaking/v1/btc_delegation/{staking_tx_hash_hex}` Description: Retrieves a specific BTC delegation by its corresponding staking transaction hash. Additional Information: -For further details on how to use these queries and additional documentation, please refer to docs.babylonchain.io. +For further details on how to use these queries and additional documentation, please refer to docs.babylonlabs.io. diff --git a/x/checkpointing/README.md b/x/checkpointing/README.md index 565e5d467..92e8ed719 100644 --- a/x/checkpointing/README.md +++ b/x/checkpointing/README.md @@ -57,7 +57,7 @@ that is included in the next block proposal. Once a valid checkpoint is generated, it is checkpointed into the Bitcoin ledger through an off-chain program -[Vigilante Submitter](https://docs.babylonchain.io/docs/developer-guides/modules/submitter). +[Vigilante Submitter](https://docs.babylonlabs.io/docs/developer-guides/modules/submitter). It is responsible for constructing Bitcoin transactions that contain outputs utilizing the [`OP_RETURN`](https://en.bitcoin.it/wiki/OP_RETURN) script code @@ -67,7 +67,7 @@ two such transactions are constructed to contain the whole checkpoint data. After their inclusion, an off-chain program called the -[Vigilante Reporter](https://docs.babylonchain.io/docs/developer-guides/modules/reporter) +[Vigilante Reporter](https://docs.babylonlabs.io/docs/developer-guides/modules/reporter) submits inclusion proofs to the [BTC Checkpoint module](../../x/btccheckpoint/README.md), which is responsible for monitoring their confirmation status and @@ -368,4 +368,4 @@ message EventConflictingCheckpoint { The Checkpointing module provides a set of queries about BLS keys the status of checkpoints, listed at -[docs.babylonchain.io](https://docs.babylonchain.io/docs/developer-guides/grpcrestapi#tag/Checkpointing). +[docs.babylonlabs.io](https://docs.babylonlabs.io/docs/developer-guides/grpcrestapi#tag/Checkpointing). diff --git a/x/epoching/README.md b/x/epoching/README.md index 5ebf0741c..ea6ab3e2c 100644 --- a/x/epoching/README.md +++ b/x/epoching/README.md @@ -557,5 +557,5 @@ message EventWrappedStakingUpdateParams { The Epoching module provides a set of queries about epochs, validators and delegations, listed at -[docs.babylonchain.io](https://docs.babylonchain.io/docs/developer-guides/grpcrestapi#tag/Epoching). +[docs.babylonlabs.io](https://docs.babylonlabs.io/docs/developer-guides/grpcrestapi#tag/Epoching). diff --git a/x/finality/README.md b/x/finality/README.md index 139d58389..63f1187ad 100644 --- a/x/finality/README.md +++ b/x/finality/README.md @@ -45,8 +45,8 @@ holders to *trustlessly* stake their bitcoins, in order to provide economic security to the Babylon chain and other Proof-of-Stake (PoS) blockchains. The protocol composes a PoS blockchain with an off-the-shelf *finality voting round* run by a set of [finality -providers](https://github.com/babylonchain/finality-provider) who receive *BTC -delegations* from [BTC stakers](https://github.com/babylonchain/btc-staker). The +providers](https://github.com/babylonlabs-io/finality-provider) who receive *BTC +delegations* from [BTC stakers](https://github.com/babylonlabs-io/btc-staker). The finality providers and BTC delegations are maintained by Babylon's [BTC Staking module](../btcstaking/README.md), and the Finality module is responsible for maintaining the finality voting round. @@ -56,7 +56,7 @@ maintaining the finality voting round. the CometBFT ledger receives *finality votes* from a set of finality providers. A finality vote is a signature under the [*Extractable One-Time Signature (EOTS)* -primitive](https://docs.babylonchain.io/assets/files/btc_staking_litepaper-32bfea0c243773f0bfac63e148387aef.pdf). +primitive](https://docs.babylonlabs.io/assets/files/btc_staking_litepaper-32bfea0c243773f0bfac63e148387aef.pdf). A block is considered finalized if it receives a quorum, i.e., votes from finality providers with more than 2/3 voting power at its height. @@ -101,7 +101,7 @@ needs to interact with Babylon as follows: provider's secret key and slash it. Babylon has implemented a [BTC staking -tracker](https://github.com/babylonchain/vigilante) daemon program that +tracker](https://github.com/babylonlabs-io/vigilante) daemon program that subscribes to equivocation evidences in the Finality module, and slashes BTC delegations under equivocating finality providers by sending their slashing transactions to the Bitcoin network. @@ -313,7 +313,7 @@ The message handlers are defined at The `MsgCommitPubRandList` message is used for committing a merkle tree constructed by a list of EOTS public randomness that will be used by a finality provider in the future. It is typically submitted by a finality provider via the -[finality provider](https://github.com/babylonchain/finality-provider) program. +[finality provider](https://github.com/babylonlabs-io/finality-provider) program. ```protobuf // MsgCommitPubRandList defines a message for committing a list of public randomness for EOTS @@ -353,7 +353,7 @@ Upon `MsgCommitPubRandList`, a Babylon node will execute as follows: The `MsgAddFinalitySig` message is used for submitting a finality vote, i.e., an EOTS signature over a block signed by a finality provider. It is typically submitted by a finality provider via the [finality -provider](https://github.com/babylonchain/finality-provider) program. +provider](https://github.com/babylonlabs-io/finality-provider) program. ```protobuf // MsgAddFinalitySig defines a message for adding a finality vote @@ -519,5 +519,5 @@ string public_key = 1; The Finality module provides a set of queries about finality signatures on each block, listed at -[docs.babylonchain.io](https://docs.babylonchain.io/docs/developer-guides/grpcrestapi#tag/Finality). +[docs.babylonlabs.io](https://docs.babylonlabs.io/docs/developer-guides/grpcrestapi#tag/Finality). diff --git a/x/zoneconcierge/README.md b/x/zoneconcierge/README.md index 046c5567a..3280bfb4d 100644 --- a/x/zoneconcierge/README.md +++ b/x/zoneconcierge/README.md @@ -497,4 +497,4 @@ the module parameters via a governance proposal. It provides a set of queries about the status of checkpointed PoS blockchains, listed at -[docs.babylonchain.io](https://docs.babylonchain.io/docs/developer-guides/grpcrestapi#tag/ZoneConcierge). +[docs.babylonlabs.io](https://docs.babylonlabs.io/docs/developer-guides/grpcrestapi#tag/ZoneConcierge).