# BasicShareManager

### Overview

`BasicShareManager` is a concrete implementation of the abstract `ShareManager`, designed to provide native ERC20-style share accounting within a modular vault system. It handles minting, burning, and tracking balances of vault shares directly through a local ERC20-compatible storage layout, without exposing standard ERC20 interfaces.

This contract is intended for setups where shares are not tokenized on-chain as ERC20s but are still tracked internally using the ERC20Upgradeable storage schema.

### Key Features

* Uses `ShareManager` for permissioning, allocation, and whitelisting logic.
* Maintains balances and total supply using `ERC20Upgradeable.ERC20Storage`.
* Internal mint/burn logic emits `IERC20.Transfer` events (for transparency or compatibility).
* Fully decoupled from standard `ERC20` interface – share transfers are governed by vault queues and mint/burn logic only.

### Storage

ERC20-style balances and supply are stored at a fixed storage slot allowing for migrations BasicShareManager ↔ TokenizedShareManager:

```solidity
bytes32 private constant ERC20StorageLocation = 0x52c6...ce00;
```

### Initialization

```solidity
function initialize(bytes calldata data) external initializer
```

* Expects a single `bytes32 whitelistMerkleRoot` (used by `ShareManager`).

### View Functions

* `activeShares()`: Returns `_totalSupply` from ERC20 storage.
* `activeSharesOf(account)`: Returns balance of `account`.

### Internal Logic

### `_mintShares(address, uint256)`

* Checks if minting is allowed via `updateChecks`.
* Increments total supply and receiver's balance.
* Emits `IERC20.Transfer(address(0), account, value)`.

Reverts if:

* `account == address(0)`
* Minting is paused or restricted by lockup, whitelist, or blacklist

### `_burnShares(address, uint256)`

* Checks if burning is allowed via `updateChecks`.
* Decreases sender's balance and total supply.
* Emits `IERC20.Transfer(account, address(0), value)`.

Reverts if:

* `account == address(0)`
* `value > account balance`
* Burning is paused or blocked

### Design Notes

* This module deliberately avoids exposing the ERC20 interface, preventing any unintended external transfers or integrations.
* It is intended for internal share accounting within vault systems, where shares are tracked but not tokenized onchain.
* All permissioning logic, including minting, burning, whitelisting, and lockup enforcement, is delegated to the inherited `ShareManager`.
* This implementation is ideal when the vault owner requires non-transferable shares for internal logic, without compliance to ERC20 or ERC4626 standards.
* It is **not appropriate** for setups where shares must be externally transferable, interoperable with third-party protocols, or conform to token standards.


---

# 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.mellow.finance/core-vaults/architecture/managers/basicsharemanager.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.