# Capital Stack

{% hint style="info" %}
For technical documentation, please see [CapitalStack](/smart-contracts/source-code/core/capitalstack.md)
{% endhint %}

A *Capital Stack* refers to the variety of economic claims against a company's assets and cashflows. It also refers to the mix of financing that a company uses to fund its operations and growth. The capital stack is composed of different forms of debt and equity.  The capital stack dictates which stakeholders receive assets in the event of a company's liquidation, recapitalization, merger, or acquisition.  

Each Mezzanine company is deployed with a capital stack.  A Mezzanine capital stack is comprised of *seniority levels* and *assets.*  Seniority levels dictate the prioritization of  the payments to stakeholders during a company's liquidation, recapitalization, etc.  Each seniority level can contain up to 15 assets, and a company can have up to 15 seniority levels.

Both seniority levels and assets are characterized by an *asset class*.  There are three different types of asset classes in Mezzanine: 

1. Common Equity
2. Preferred Equity
3. Debt

The following truisms exist for every capital stack in Mezzanine:

1. A *debt* seniority level cannot be inserted below a *common equity* or *preferred equity* seniority level
2. A *preferred equity* seniority level cannot be inserted below a *common equity* seniority level nor above a *debt* seniority level
3. A *common equity* seniority level  cannot be inserted above a *preferred equity* or *debt* seniority level 

Mezzanine assets cannot be inserted into a seniority level that does not match their asset class.  For example, only Preferred and Common shares can be inserted into common equity and preferred equity seniority levels, respectively.  

Below is an example of a capital stack in Mezzanine:

<figure><img src="/files/fyaPScOWs3a0Owxd5oKd" alt="" width="330"><figcaption></figcaption></figure>

In the above example, debt asset, *F,* would be paid out before *D* and *E* in the event of a company's liquidation, while *D* and *E* would be paid out before the liquidation preferences of *B* and *C*. &#x20;

Unlike departments and modules, developers cannot add custom assets to the capital stack. Third-party creations are likely prone to potential errors that conflict with other functions, like liquidation. Moreover, untested asset types may lead to unpredictable methods of exploitation.

Each Mezzanine company is created with a single Common Equity seniority level that contains its common shares.  This remain as the entire capital stack until the company decides to add to it. &#x20;

## Share Classes

All shares represent assets that have equity-like claims to underlying assets. Shareholders also control governance. There are two types of share classes in Mezzanine: common shares and preferred shares.  There are a few notable differences between the two:

* Each Mezzanine Company can have only a *single* set of common shares but can have *multiple* sets of preferred shares
* Common shares will always have a *voting weight* of one, while the voting weight of preferred shares is bespoke
* Common shares have no liquidation preference, while preferred shares *can* have a liquidation preference

More details on the following [Share Classes](/protocol/capital-stack/share-classes.md) section.

## Debt

*The initial version of the Mezzanine protocol has no debt assets and does not yet support liquidation, recapitalization, mergers, or acquisitions. Debt assets can easily be enabled modularly by the Mezzanine team without upgrading contracts. Liquidation, recapitalization, etc. will be added via contract upgrades.*


---

# 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.mezzanine.xyz/protocol/capital-stack.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.