open-index/open-npm huggingface dataset:
npm package: @satlayer/bvs-guardrail
Description: BVS Guardrail is a smart contract that serves as a final check for the slashing request before it can be finalized.
Latest version: 2.4.0

# BVS Guardrail

BVS Guardrail is a smart contract that serves as a final check for the slashing request before it can be finalized.

## Overview

BVS Guardrail implements a voting system based on the [CW3 multisig specification](https://github.com/CosmWasm/cw-plus/blob/main/packages/cw3/README.md) and [CW4 group membership](https://github.com/CosmWasm/cw-plus/blob/main/packages/cw4/README.md).
It ensures
that slashing requests are only finalized
if they have been approved by a sufficient number of eligible voters within the specified voting period.

This contract is largely adapted from [cw3-flex-multisig](https://github.com/CosmWasm/cw-plus/tree/main/contracts/cw3-flex-multisig) and [cw4-group](https://github.com/CosmWasm/cw-plus/tree/main/contracts/cw4-group) implementations.

## Usage

The contract is initialized with a set of members (voters) and a threshold configuration that determines how many votes are required for a proposal to pass. Once initialized, authorized members can create and vote on slashing proposals.

Proposals are created when a slashing request is initiated.
Members can vote on these proposals within a specified voting period.
If the proposal receives enough votes before the voting period ends, it is considered approved and the slashing request can be finalized.
npm package: @satlayer/bvs-pauser
Description: The BVS Pauser contract is a specialized smart contract designed to provide a centralized pause mechanism for the entire ecosystem. It allows an authorized owner to pause and unpause contract functionality across the system, which is crucial for emergency
Latest version: 2.4.0

# BVS Pauser

The BVS Pauser contract is a specialized smart contract
designed to provide a centralized pause mechanism for the entire ecosystem.
It allows an authorized owner to pause and unpause contract functionality across the system,
which is crucial for emergency response to security incidents, bugs, or other critical issues.
Allowing for quick and efficient responses to any issues that may arise.

The contract provides these main query functions:

```rust
pub enum QueryMsg {
    #[returns(IsPausedResponse)]
    IsPaused {
        /// The (contract: Addr) calling this
        #[serde(rename = "c")]
        contract: String,
        /// The (method: ExecuteMsg) to check if it is paused
        #[serde(rename = "m")]
        method: String,
    },

    #[returns(CanExecuteResponse)]
    CanExecute {
        /// The (contract: Addr) calling this
        #[serde(rename = "c")]
        contract: String,
        /// The (sender: Addr) of the message
        #[serde(rename = "s")]
        sender: String,
        /// The (method: ExecuteMsg) to check if it is paused
        #[serde(rename = "m")]
        method: String,
    },
}
```

### Integration with Other Contracts

The BVS Pauser contract is designed to be easily integrated with other contracts in the ecosystem.
For downstream contracts,
you don't have
to manually implement query functions to check if a contract is paused or if a sender can execute a method.
The BVS Pauser provides a simple API for integration:

1. During the instantiation of your contract, set the address of the pauser contract:

```rust
#[cfg_attr(not(feature = "library"), entry_point)]
pub fn instantiate(/*...*/) -> Result<Response, ContractError> {
    let pauser = deps.api.addr_validate(&msg.pauser)?;
    bvs_pauser::api::set_pauser(deps.storage, &pauser)?;
}
```

2. In your execute function, check if the operation is allowed before proceeding:

```rust
#[cfg_attr(not(feature = "library"), entry_point)]
pub fn execute(/*...*/) -> Result<Response, ContractError> {
    bvs_pauser::api::assert_can_execute(deps.as_ref(), &env, &info, &msg)?;

    // Continue with execution if not paused
}
```

This simple integration ensures that all BVS contracts respect the global pause state,
securing and manageable ecosystem.
npm package: @satlayer/bvs-rewards
Description: The BVS Rewards contract manages the distribution and claiming of rewards in the SatLayer ecosystem. It enables Services to distribute rewards to Operators and Stakers (collectively called Earners) based on their contributions to the network.
Latest version: 2.4.0

# BVS Rewards

The BVS Rewards contract manages the distribution and claiming of rewards in the SatLayer ecosystem.
It enables Services to distribute rewards to Operators and Stakers
(collectively called Earners) based on their contributions to the network.

## Contract Functions

### Distribution Functions

- `DistributeRewards`: Services distribute rewards by posting a Merkle root
  - Requires sufficient token allowance (CW20) or funds (Bank)
  - Updates the current Merkle root for the specified Service and token
  - Sends the specified number of tokens from the service to the contract

### Claiming Functions

- `ClaimRewards`: Earners claim rewards by providing a Merkle proof for the (service, token) pair
  - Verifies the proof against the stored Merkle root
  - Transfers the claimed rewards to the recipient
  - Updates claimed rewards tracking

### Query Functions

- `DistributionRoot`: Query the Merkle root for a Service and token
- `Balance`: Query the rewards balance available for a Service and token
- `ClaimedRewards`: Query the claimed rewards for a Service, token, and Earner

## Rewards Workflow

Refer to the [Rewards](/architecture/rewards) section for a detailed overview of how rewards are distributed,
and claimed in the SatLayer ecosystem.

## Important Notes

- Non-standard CW20 tokens (e.g., with fee-on-transfer mechanisms) are not supported
- The contract maintains state for distribution roots, balances, and claimed rewards
- Rewards amount is cumulative
npm package: @satlayer/bvs-vault-bank
Description: The BVS Vault Bank is a specialized vault contract designed to support native bank tokens as the underlying asset in the SatLayer ecosystem. It enables operators to manage deposits and withdrawals of native tokens like `ubbn` (the native token of the Baby
Latest version: 2.4.0

# BVS Vault Bank

The BVS Vault Bank is a specialized vault contract
designed to support native bank tokens as the underlying asset in the SatLayer ecosystem.
It enables operators to manage deposits and withdrawals of native tokens
like `ubbn` (the native token of the Babylon project).

The Vault Bank implements the ERC-4626 tokenized vault standard,
providing a standardized interface for yield-bearing vaults.
It manages the relationship between deposited assets and shares,
allowing for efficient tracking of user deposits and their corresponding value.

- **Native Token Support**: Handles native bank tokens as the underlying asset
- **Share-Based Accounting**: Uses a share system to track user deposits and their value

## Contract Functions

### Execute Functions

- `DepositFor`: Deposit native tokens into the vault for a recipient
- `QueueWithdrawalTo`: Queue a withdrawal request for later processing
- `RedeemWithdrawalTo`: Process a queued withdrawal request

### Query Functions

- `Shares`: Get the number of shares owned by a staker
- `Assets`: Get the asset value of shares owned by a staker
- `ConvertToAssets`: Convert a share amount to its asset value
- `ConvertToShares`: Convert an asset amount to its share value
- `TotalShares`: Get the total number of shares in the vault
- `TotalAssets`: Get the total asset value in the vault
- `QueuedWithdrawal`: Get information about a queued withdrawal
- `VaultInfo`: Get general information about the vault

## Deposit and Withdrawal Process

The Vault Bank manages deposits and withdrawals through a share-based system:

1. When users deposit assets, they receive shares proportional to their deposit value
2. The share price (exchange rate) is determined by the total assets and total shares in the vault
3. When users withdraw, their shares are converted back to assets based on the current exchange rate
4. If the operator is not actively validating, withdrawals are queued for later processing

The vault implements a withdrawal queue to handle situations where immediate withdrawals are not possible:

1. Users request a withdrawal via `QueueWithdrawalTo`
2. The request is stored with a timestamp and the current exchange rate
3. After the lock period expires, users can redeem their withdrawal via `RedeemWithdrawalTo`
4. The withdrawal is processed using the exchange rate from when it was queued
npm package: @satlayer/bvs-vault-cw20
Description: The BVS Vault CW20 is a specialized vault contract designed to support CW20 tokens as the underlying asset in the SatLayer ecosystem. It enables operators to manage deposits and withdrawals of CW20 tokens, providing a standardized interface for token mana
Latest version: 2.4.0

# BVS Vault CW20

The BVS Vault CW20 is a specialized vault contract
designed to support CW20 tokens as the underlying asset in the SatLayer ecosystem.
It enables operators to manage deposits and withdrawals of CW20 tokens,
providing a standardized interface for token management.

The Vault CW20 implements the ERC-4626 tokenized vault standard,
providing a standardized interface for yield-bearing vaults.
It manages the relationship between deposited CW20 tokens and shares,
allowing for efficient tracking of user deposits and their corresponding value.

- **CW20 Token Support**: Handles CW20 tokens as the underlying asset
- **Share-Based Accounting**: Uses a share system to track user deposits and their value

## Contract Functions

### Execute Functions

- `DepositFor`: Deposit CW20 tokens into the vault for a recipient
- `QueueWithdrawalTo`: Queue a withdrawal request for later processing
- `RedeemWithdrawalTo`: Process a queued withdrawal request

### Query Functions

- `Shares`: Get the number of shares owned by a staker
- `Assets`: Get the asset value of shares owned by a staker
- `ConvertToAssets`: Convert a share amount to its asset value
- `ConvertToShares`: Convert an asset amount to its share value
- `TotalShares`: Get the total number of shares in the vault
- `TotalAssets`: Get the total asset value in the vault
- `QueuedWithdrawal`: Get information about a queued withdrawal
- `VaultInfo`: Get general information about the vault

## Deposit and Withdrawal Process

The Vault CW20 manages deposits and withdrawals through a share-based system:

1. When users deposit CW20 tokens, they receive shares proportional to their deposit value
2. The share price (exchange rate) is determined by the total assets and total shares in the vault
3. When users withdraw, their shares are converted back to CW20 tokens based on the current exchange rate
4. If the operator is not actively validating, withdrawals are queued for later processing

The vault implements a withdrawal queue to handle situations where immediate withdrawals are not possible:

1. Users request a withdrawal via `QueueWithdrawalTo`
2. The request is stored with a timestamp and the current exchange rate
3. After the lock period expires, users can redeem their withdrawal via `RedeemWithdrawalTo`
4. The withdrawal is processed using the exchange rate from when it was queued
npm package: @satlayer/bvs-vault-factory
Description: The BVS Vault Factory is a contract that enables operators to deploy new vault contracts on the SatLayer ecosystem. It serves as a centralized deployment mechanism, ensuring that only approved vault types can be created and that they are properly configur
Latest version: 2.4.0

# BVS Vault Factory

The BVS Vault Factory is a contract that enables operators to deploy new vault contracts on the SatLayer ecosystem.
It serves as a centralized deployment mechanism,
ensuring that only approved vault types can be created
and that they are properly configured to work with the SatLayer infrastructure.

The Vault Factory maintains a registry of approved code IDs for different vault types,
which can be updated by the contract owner.
This ensures that only secure and compatible vault implementations can be deployed through the factory.

## Contract Functions

### Execute Functions

- `DeployCw20Vault`: Deploy a new CW20 vault for a specific CW20 token
- `DeployBankVault`: Deploy a new bank vault for a specific native token denomination
- `SetCodeId`: Set the code ID for a specific vault type (only owner can call)

### Query Functions

- `CodeId`: Get the code ID for a specific vault type

## Vault Deployment Process

The Vault Factory manages the deployment of new vaults through a controlled process:

1. The contract owner sets approved code IDs for different vault types using `SetCodeId`
2. Operators can deploy new vaults using `DeployCw20Vault` or `DeployBankVault`
3. The factory instantiates a new vault contract with the appropriate code ID
4. The factory configures the vault with the correct router address and operator
5. The new vault is ready to be whitelisted by the router for accepting deposits

### Supported Vault Types

The Vault Factory supports two main types of vaults:

1. **CW20 Vaults**: For managing CW20 token deposits and withdrawals
2. **Bank Vaults**: For managing native token deposits and withdrawals

Each vault type has its own code ID that must be set by the contract owner before deployment.
npm package: @satlayer/bvs-vault-router
Description: The BVS Vault Router is a central contract that manages the interaction between vaults and other contracts in the SatLayer ecosystem. It serves as the entry/exit point for all vaults, controlling that vaults can accept deposits and managing the relationsh
Latest version: 2.4.0

# BVS Vault Router

The BVS Vault Router is a central contract
that manages the interaction between vaults and other contracts in the SatLayer ecosystem.
It serves as the entry/exit point for all vaults,
controlling that vaults can accept deposits and managing the relationship between operators and their vaults.

The Vault Router provides essential functionality for the SatLayer ecosystem by:

1. Managing the whitelist status of vaults, determining which vaults can accept deposits
2. Tracking the relationship between operators and their vaults
3. Querying the registry to determine if operators are validating services
4. Managing withdrawal lock periods for vaults

## Contract Functions

### Execute Functions

- `SetVault`: Set a vault contract and its whitelist status (only owner can call)
- `SetWithdrawalLockPeriod`: Set the lock period for withdrawals (only owner can call)
- `TransferOwnership`: Transfer ownership of the contract to a new owner

### Query Functions

- `IsWhitelisted`: Check if a vault is whitelisted and can accept deposits
- `IsValidating`: Check if an operator is validating services
- `ListVaults`: List all vaults with pagination support
- `ListVaultsByOperator`: List vaults managed by a specific operator
- `WithdrawalLockPeriod`: Get the current withdrawal lock period

## Whitelisting Process

The Vault Router manages vaults through a whitelisting process:

1. The owner adds a vault to the router using `SetVault` with `whitelisted: true`
2. The router verifies that the vault is connected to it
3. The router creates a mapping between the operator and the vault
4. Whitelisted vaults can accept deposits
5. The router can check if an operator is validating services by querying the registry