# Changelog

## DistributionV5 -> DepositPool

The `DistributionV5` contract was renamed to `DepositPool` because the old name no longer reflects its role — the core reward distribution logic has been moved out of this contract.

This contract no longer accumulates or holds user stake balances directly for yield generation. Instead, all deposits are forwarded to the `Distributor` contract, which manages the real token flow and yield accounting.

### Storage Refactoring and Responsibility Separation

Many of the storage variables from `DistributionV5` have been deprecated and renamed to `unusedStorage` to maintain upgradeability alignment. The actual data and responsibilities tied to these variables were migrated to more specialized contracts:

* `rewardPools` and `l1Sender` data moved to `RewardPool` and `Distributor` .
* `poolsLimits` moved to `rewardPoolsProtocolDetails` .
* Introduced new storage fields such as:
  * `distributor` — central reward distributor.
  * `rewardPoolsProtocolDetails` — configuration per reward pool.
  * `isMigrationOver` — flag to mark pool-level migration completion.

```solidity
/** @dev UPGRADE `DepositPool`, v7. Storage updates, add few deposit pools. */
/** @dev This flag determines whether the migration has been completed. */
bool public isMigrationOver;

/** @dev `Distributor` contract address. */
address public distributor;

/** @dev Contain information about rewards pools needed for this contract. */
mapping(uint256 => RewardPoolProtocolDetails) public rewardPoolsProtocolDetails;
/** @dev UPGRADE `DepositPool`, v7 end. */

```

**Motivation**: cleaner architecture, modularity, upgrade-safe alignment.

### Delegated Claim Functionality

Two mappings were introduced to support trusted claim delegation:

* `claimSender`: allows a staker to whitelist addresses permitted to claim on their behalf.
* `claimReceiver`: enables users to automatically set L2 receiver and allow anyone to claim behalf the staker.

```solidity
/** @dev UPGRADE `DistributionV6` storage updates, add addresses allowed to claim. Add whitelisted claim receivers. */
mapping(uint256 => mapping(address => mapping(address => bool))) public claimSender;
mapping(uint256 => mapping(address => address)) public claimReceiver;
/** @dev UPGRADE `DistributionV6` end. */

```

**Motivation**: unlocks possibility to allow anyone claim behalf staker, for example for Builder bucket.

### One-Time Migration Mechanism

New `migrate` function allows a pool to finalize its state migration after a contract upgrade. If there are any extra tokens (yield), they are forwarded to the `Distributor`, and the pool gets marked as migrated.

```solidity
function migrate(uint256 rewardPoolIndex_) external onlyOwner {
  require(!isMigrationOver, "DS: the migration is over");
  ...

  IDistributor(distributor).supply(rewardPoolIndex_, totalDepositedInPublicPools);

  isMigrationOver = true;

  emit Migrated(rewardPoolIndex_);
}
```

**Motivation**: ensures smooth, non-breaking transition to the new verision.

### Distributor-Centric Reward Logic

Part of reward distribution delegated to the `Distributor` contract. This affects related changes in many functions that cannot be described block by block and require reviewing the pull request.

**Motivation**: separate part of reward calculations to implement the new logic.

## L1MessageReceiver -> L1MessageReceiverV2

### Centralized Integration via Distributor

The `L1MessageReceiverV2` contract no longer interacts directly with the `DistributionV5` contract. Instead, it now connects through the unified `Distributor` contract.

This design ensures that the system maintains a single authoritative point for defining and interacting with the `L1MessageReceiverV2`.

**Motivation:** since there can be multiple `DepositPool` contracts, it’s inefficient and redundant to store the `L1MessageReceiverV2` address in each one — moving this to the `Distributor` improves maintainability and consistency.

### Yield Management and Uniswap Integration

As `L1MessageReceiverV2` is now responsible for storing and managing the protocol’s accumulated yield, it includes new functionality for interacting with Uniswap.

**Motivation:** this allows the contract to actively manage yield (e.g., perform token swaps) before bridging operations.

## RewardPool

The `RewardPool` contract now contains significant portions of logic that were previously handled by the `DistributionV5` contract. This change reflects a broader architectural refactor that distributes responsibilities across dedicated modules.

The `RewardPool` contract now encapsulates the emission logic that was previously part of `DistributionV5`. Specifically, it is responsible for calculating MOR token emissions over time, determining the reward amounts to be distributed in each period, and managing the allocation of rewards across predefined user buckets (such as Capital, Builder, Compute, etc.). 

**Motivation:** by consolidating this logic, the system ensures consistency and avoids duplication across multiple `DepositPool` instances.

## ChainLinkDataConsumer and Distributor

The new protocol architecture introduces the `ChainLinkDataConsumer` and `Distributor` contracts to support expanded yield strategies for newly added staking tokens. These contracts are required due to the introduction of additional yield-generating mechanisms.

The `Distributor` contract handles the logic for reward allocation and incorporates integration with Aave, where deposited tokens can be used to generate yield. However, the actual Aave yield is not returned to users — instead, it is used to inform the protocol’s internal reward calculations and determine how much MOR should be distributed to each `DepositPool`.

The `ChainLinkDataConsumer` contract integrates with Chainlink oracles to fetch real-time price data  necessary for calculating MOR rewards.<br>

## Links

<https://github.com/MorpheusAIs/SmartContracts/pull/53>


---

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