# strBTC Rebasing Token

**`strBTC` is implemented as a rebasing token**, meaning its balance in user wallets may automatically adjust over time to reflect accrued yield or protocol-level economic changes, without altering each individual wallet balance directly. This mechanism allows `strBTC` holders to passively receive proportional yield—sourced from native BTC strategies and DeFi participation—without needing to stake or lock their tokens. Rebasing ensures that yield distribution is frictionless and gas-efficient, as value increases are reflected through balance updates rather than manual claims. Importantly, `strBTC`’s rebasing logic is transparent, deterministic, and governed by the Stroom protocol.

The **`strBTC`** contract implements a rebasing token with key public functions enabling minting, burning, and supply adjustments. Core methods include:

* `mint(address to, uint256 amount, bytes calldata signature)` — Mints `amount` of strBTC tokens to the `to` address. Access-controlled via the `onlyValidator` modifier from `ValidatorMessageReceiver`, ensuring only a correctly signed message can be used to mint tokens after BTC deposits are confirmed.
* `redeem(uint256 _amount, string calldata BTCAddress)` — Burns `_amount` of strBTC from the `msg.sender` address and signals validators to process payout to `BTCAddress`. 
* `mintRewards(uint256 nonce, uint256 delta, bytes calldata signature)` — Adjusts the total supply by `delta`, triggering a proportional rebase of all balances to reflect yield or protocol-level adjustments. This function is restricted by `onlyValidator`.
* Standard ERC-20 functions `transfer`, `transferFrom`, `approve`, and `allowance` provide typical token transfer and allowance management.
* `balanceOf(address account)` — Returns the user’s current `strBTC` balance, factoring in rebasing adjustments dynamically.

The **`ValidatorMessageReceiver`** contract is a core security component used by `strBTC` to enforce strict access control on sensitive operations such as minting and rebasing. It implements a **validator-based permission model** where only messages signed by a predefined set of authorized validators are accepted.

Key features of `ValidatorMessageReceiver`:

* **Validator Set Management:** The contract stores a joint public key of validators authorized to approve actions. The public key is derived using the FROST algorithm for Schnorr signatures. This pubkey can be updated via governance to adapt to changes in the federation or operator group.
* **Message Verification:** The contract verifies incoming signed messages against the validator public key using the standard Schnorr signature scheme. This cryptographic verification ensures that only messages endorsed by a sufficient quorum of validators can trigger state changes.
* **Replay Protection & Message Uniqueness:** To prevent replay attacks or double executions, `ValidatorMessageReceiver` implements nonce or message hash tracking, ensuring each validated message is only executed once.

By integrating `ValidatorMessageReceiver`, the `strBTC` contract ensures that minting and rebasing operations can only be performed upon valid, authorized consensus from the federation of validators.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.stroom.network/stroom/smart-contracts/strbtc-rebasing-token.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.