> 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/core-concepts/shares.md).

# Shares

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/core-concepts/subscriptions.md) and [redemptions](/funds/infrastructure/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/core-concepts/roles-and-operators.md)).
* **`UUPSUpgradeable`** — the contract is a proxy. Each fund gets its **own implementation** (deployed by the [factory](/funds/infrastructure/deployment.md)), so upgrading one fund never affects another.

### Request-based, not ERC-4626

While inspired by [ERC-4626](https://eips.ethereum.org/EIPS/eip-4626) tokenized 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/core-concepts/subscriptions.md) and [Redemptions](/funds/infrastructure/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 **normalized USD units with 8 decimals**; the share token itself uses **18 decimals**. NAV is computed onchain by the [NAV Calculator](/funds/infrastructure/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/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/core-concepts/roles-and-operators.md)); integrators read it with `getApprovedAssets` / `getApprovedAsset` / `isApprovedAsset` (see [List approved assets](/funds/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 dynamically by asking a question.

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

```
GET https://docs.kpk.io/funds/infrastructure/core-concepts/shares.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.