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
andl1Sender
data moved toRewardPool
andDistributor
.poolsLimits
moved torewardPoolsProtocolDetails
.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
Last updated
Was this helpful?