> For the complete documentation index, see [llms.txt](https://gitbook.mor.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gitbook.mor.org/smart-contracts/documentation/builders-protocol/v4-protocol/contracts.md).

# Contracts

## Protocol architecture

<figure><img src="https://2371043446-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl7W52NNhIIACGv1fus80%2Fuploads%2FH6bohtc5uJWGUrMqnXeT%2Fimage.png?alt=media&amp;token=3d9cf7b0-954d-4fa8-ae08-69b6dfe843b0" alt=""><figcaption></figcaption></figure>

## Core contracts

### BuildersV4

The `BuildersV4` contract governs the protocol’s core logic and state. It facilitates the creation and configuration of Subnets, user staking and withdrawal operations, and the dynamic reward distribution process.

A user can create a new Subnet by specifying parameters such as the administrator, claim administrator, minimum deposit... If a creation fee is configured, it is collected and forwarded to the appropriate treasury address via the `FeeConfig` contract.

Users may deposit MOR tokens into a Subnet, increasing its total stake and share in the global reward pool. Withdrawals are subject to a lock period defined per Subnet, and users must either maintain the minimum required deposit or fully exit their stake. Upon deposit, withdrawal, or reward claim, the contract recalculates reward allocations using the current emission rate provided by the `RewardPool` contract. This emission rate is scaled by the “network share” parameter to determine the portion allocated to Builders in the specific chain.

The administrator or claim administrator of a Subnet can trigger a claim, transferring accrued MOR rewards to a specified recipient address. Any applicable fee is deducted and transferred to the treasury. All Subnet and global statistics are updated with each operation to ensure accurate state tracking.

### BuildersTreasuryV2

`BuildersTreasuryV2` holds MOR tokens for distribution to Subnets. It receives reward claims initiated by the `BuildersV4` contract and securely transfers tokens to recipients. The treasury also tracks the total amount of claimed rewards.

Only the `BuildersV4` contract is authorized to execute reward payouts. The owner retains the ability to change the `BuildersV4` address and manually withdraw MOR tokens when needed, for purposes such as migration or administrative recovery.

### [RewardPool](/smart-contracts/documentation/distribution-protocol/v7-protocol/contracts/rewardpool.md)

See the documentation for this contract [here](/smart-contracts/documentation/distribution-protocol/v7-protocol/contracts/rewardpool.md).

### [Fee config](/smart-contracts/documentation/builders-protocol/v2-protocol/contracts/feeconfig.md)

See the documentation for this contract [here](/smart-contracts/documentation/builders-protocol/v2-protocol/contracts/feeconfig.md).

## Periphery

### OpenZeppelin

Used extensively across contracts to support secure access control and upgradeability:

* `OwnableUpgradeable` – enables ownership access control.
* `UUPSUpgradeable` – facilitates contract upgradeability via the UUPS (Universal Upgradeable Proxy Standard) pattern.

Links:

* <https://docs.openzeppelin.com/contracts/4.x/access-control>
* <https://docs.openzeppelin.com/contracts/4.x/api/proxy>


---

# 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://gitbook.mor.org/smart-contracts/documentation/builders-protocol/v4-protocol/contracts.md?ask=<question>&goal=<user_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.
