# 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&#x26;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](https://gitbook.mor.org/smart-contracts/documentation/distribution-protocol/v7-protocol/contracts/rewardpool)

See the documentation for this contract [here](https://gitbook.mor.org/smart-contracts/documentation/distribution-protocol/v7-protocol/contracts/rewardpool).

### [Fee config](https://gitbook.mor.org/smart-contracts/documentation/builders-protocol/v2-protocol/contracts/feeconfig)

See the documentation for this contract [here](https://gitbook.mor.org/smart-contracts/documentation/builders-protocol/v2-protocol/contracts/feeconfig).

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