> For the complete documentation index, see [llms.txt](https://docs.kpk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kpk.io/funds/infrastructure/architecture/core-concepts/shares.md). # Shares The kpkShares ERC-20 token, pro-rata fund ownership with a request-based mint/burn model. Shares represent **proportional ownership of the fund**. When users subscribe, new shares are minted to reflect their contribution. When they redeem, those shares are burned. At any point, a holder's share balance corresponds to their fraction of the fund's total Net Asset Value (NAV). ## The `kpkShares` contract Each fund's shares are an instance of **`kpkShares`**, an **ERC-20 token** (18 decimals) that also serves as the **onchain interface** for [subscriptions](/funds/infrastructure/architecture/core-concepts/subscriptions.md) and [redemptions](/funds/infrastructure/architecture/core-concepts/redemptions.md). It is built on OpenZeppelin's upgradeable contracts: * **`ERC20Upgradeable`**: standard token behaviour (`transfer`, `approve`, `balanceOf`, `totalSupply`, …). * **`AccessControlUpgradeable`**: the `DEFAULT_ADMIN_ROLE` / `OPERATOR` permission model (see [Roles and operators](/funds/infrastructure/architecture/core-concepts/roles-and-operators.md)). * **`UUPSUpgradeable`**: the contract is a proxy. Funds deployed by the current ([salt v4](/funds/infrastructure/architecture/deployment/deployment-addresses.md)) [factory](/funds/infrastructure/architecture/deployment.md) share one implementation per chain, while earlier funds each have their own. Upgrading one fund never affects another either way, because each proxy upgrades only its own implementation pointer. ### Request-based, not ERC-4626 While inspired by [ERC-4626](https://eips.ethereum.org/EIPS/eip-4626) tokenised vaults, `kpkShares` does **not** expose direct `deposit`/`withdraw`. Every inflow and outflow goes through an **operator-approved request**, an approach closer to [ERC-7540](https://eips.ethereum.org/EIPS/eip-7540) (asynchronous vaults). Concretely: 1. A user submits a request (`requestSubscription` / `requestRedemption`). Their assets, or shares, are moved into **escrow** inside the `kpkShares` contract while the request is `PENDING`. 2. An operator settles a batch of requests at a share price, minting or burning accordingly. This lets the fund batch requests, control execution, and manage inflows and outflows from a risk and liquidity perspective. See [Subscriptions](/funds/infrastructure/architecture/core-concepts/subscriptions.md) and [Redemptions](/funds/infrastructure/architecture/core-concepts/redemptions.md) for the full lifecycle. ## Share price and decimals The **price of a share** is the total NAV divided by the circulating supply. Share prices are expressed in **normalised USD units with 8 decimals**; the share token itself uses **18 decimals**. NAV is computed onchain by the [NAV Calculator](/funds/infrastructure/architecture/core-concepts/nav.md); the price used to settle a batch of requests is submitted by the operator and stored per asset as the *last settled price*. The contract exposes pure conversion helpers (both take a `sharesPrice` in 8-decimal USD): ```solidity // shares = (assetAmount * 10^18 * 1e8) / (sharesPrice * 10^assetDecimals) function assetsToShares(uint256 assetAmount, uint256 sharesPrice, address subscriptionAsset) external view returns (uint256); // assets = (shares * sharesPrice * 10^assetDecimals) / (1e8 * 10^18) function sharesToAssets(uint256 shares, uint256 sharesPrice, address redemptionAsset) external view returns (uint256); ``` For computing minimums with the *last settled* price, prefer `previewSubscription` / `previewRedemption`; see [Calculate share price](/funds/kpk-fund-integration/calculate-share-price.md). ## Approved assets A fund can accept more than one asset. Each approved asset is described by: ```solidity struct ApprovedAsset { address asset; // ERC-20 token address string symbol; // e.g. "USDC" uint8 decimals; // asset decimals (max 36) bool isFeeModuleAsset; // counts toward performance-fee calculations bool canDeposit; // approved for subscriptions bool canRedeem; // approved for redemptions } ``` The **base asset** set at deployment is automatically flagged `isFeeModuleAsset = true`. Operators manage the asset list with `updateAsset` (see [Roles and operators](/funds/infrastructure/architecture/core-concepts/roles-and-operators.md)); integrators read it with `getApprovedAssets` / `getApprovedAsset` / `isApprovedAsset` (see [List approved assets](/funds/kpk-fund-integration/list-approved-assets.md)). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.kpk.io/funds/infrastructure/architecture/core-concepts/shares.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.