Changelog

From v5 to v7

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.

/** @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.

/** @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.

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.

Links

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