Skip to main content

​
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 onchain 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:

​
Initialization

  • 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.