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

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