> 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.md).

# Builders protocol

The protocol is deployed on Base and Arbitrum One networks. It is designed to distribute MOR rewards among builders bucket based on user staking activity.

## Changelog

#### v1

Includes the basic version of the protocol. Anyone can create a Subnet by defining a set of parameters. Users can stake MOR tokens within a specific Subnet. Based on the total amount staked in each Subnet, that Subnet receives a share of the global MOR rewards, calculated proportionally to the total stake across all Subnets.

Each subnet has a `claimLockEnd` parameter, which defines a period during which rewards cannot be claimed. In return, the Subnet receives a multiplier to its stake, increasing its reward share.

Rewards are allocated to subnets when the Morpheus multisig transfers MOR tokens to a dedicated protocol contract. After that, any interaction — staking, withdrawing, or claiming — triggers reward calculations. Only the subnet admin can claim rewards. The distribution of those rewards among individual participants is handled outside the current protocol scope. The more frequently the multisig sends MOR tokens for distribution, the fairer the reward distribution across subnets will be.

#### v2 - current

Contains a fix for a bug related to the incorrect calculation of virtual stake when a high `claimLockEnd` was set for a Subnet. The issue caused the virtual stake to grow disproportionately, distorting reward distribution among Subnets.

#### v3

Was under development but ultimately rejected due to a mismatch with the current state of the protocol and its long-term goals. The proposed changes in v3 were deemed incompatible with the intended architecture and direction of the current protocol.

#### v4 - proposed

This version removes virtual deposits and multipliers, making the `claimLockEnd` mechanism obsolete. Subnet structure has been simplified — the start time and claim lock fields were removed. Instead, a metadata field was added, along with a secondary address allowed to claim rewards on behalf of the Subnet.

Subnet identifiers have been updated to include chainId, allowing subnets with the same name to exist on different blockchains without conflicts. Existing subnets retain their original identifiers.

The reward logic has also changed. Instead of waiting for the Morpheus multisig to send tokens for distribution, the protocol now uses a MOR emission curve to allocate virtual rewards in real time. The multisig is now responsible only for ensuring the reward distribution contract has enough MOR balance to fulfill claims. A dedicated share for the entire network was introduced to enable proper reward calculation across multiple chains.

{% content-ref url="/pages/jC1XGWF1PrqKFFa0JcoX" %}
[v2 Protocol](/smart-contracts/documentation/builders-protocol/v2-protocol.md)
{% endcontent-ref %}

{% content-ref url="/pages/9iIskLw6oDxqIRZPDu0i" %}
[v4 Protocol](/smart-contracts/documentation/builders-protocol/v4-protocol.md)
{% endcontent-ref %}


---

# 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://gitbook.mor.org/smart-contracts/documentation/builders-protocol.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.