Contracts
This section provides a high-level description of the core contracts in the protocol and their responsibilities within the system.
Protocol architecture
Ethereum core contracts
The DepositPool contract is the legacy core staking vault of the protocol’s earlier architecture. It serves as the primary entry point for users to stake their supported tokens (such as stETH, wBTC...) directly into the system. Each supported deposit token is expected to have a dedicated instance of this contract, isolating accounting, multipliers, and reward logic on a per-token basis. This means that multiplier effects, such as claim lock or referral boosts, apply only within the context of that specific deposit token and do not influence other pools.
This contract does not store the deposited assets itself. Upon staking, tokens are immediately transferred to the Distributor, ensuring management of funds and consistent application of reward mechanics across the protocol.
Each DepositPool is tied to a single staking token, enabling modular handling of multiple asset types within the broader system. While the reward logic is centralized in the Distributor, the DepositPool provides a clean interface for managing user interactions and enforcing protocol-level staking rules at the token level.
The Distributor contract plays a key role in the protocol architecture, being responsible for calculating the total MOR token yield for each DepositPool. It operates at the pool level rather than the user level and calculate the rewards for the DepositPool, which then determines how to distribute MOR among its own stakers.
The Distributor integrates with the Aave protocol to deposit user assets (such as USDC, wBTC...) and generate real yield. The contract uses Chainlink oracles to fetch up-to-date price data. This ensures a fair and transparent conversion of real yield into the base token amount. The resulting yield serves as the basis for calculating MOR rewards within the protocol.
Additionally, the Distributor interacts directly with the RewardPool contract, which contains the emission curve logic for MOR emission. This is necessary to calculate the amount of rewards that need to be distributed over a specific period of time.
The ChainLinkDataConsumer contract in the protocol is responsible for normalizing the value of yield accrued from various staking tokens by converting it to a common base token (e.g., USD). It integrates with Chainlink’s decentralized oracle network to fetch reliable and up-to-date price feeds for each supported staking token.
This price data is not used to calculate MOR token emissions directly. Instead, it ensures that yield from different sources (e.g., stETH, wETH, cbBTC...) is fairly and consistently compared and aggregated before being passed into the reward logic. For example, 1 unit of stETH and 1 unit of cbETH might not have equal value — the ChainLinkDataConsumer contract provides the conversion rate so their contributions can be measured proportionally in the base currency.
By doing so, it enables accurate, token-agnostic reward accounting and ensures that users are rewarded fairly regardless of which staking asset they contributed.
See the documentation for this contract here.
Handles cross-chain messaging from Ethereum (L1) to Arbitrum (L2). It sends reward data to the L2MessageReceiver via LayerZero, triggering the minting of MOR tokens. Additionally, it transfers stETH-based yield earned by the Morpheus protocol to L2TokenReceiverV2 using the Arbitrum Bridge. This ensures that both reward data and actual assets flow securely to the L2 environment for distribution and liquidity support.
This contract holds protocol-generated yield in various tokens, depending on active DepositPools. To efficiently convert these assets into wstETH for bridging, the contract integrates with Uniswap v3, leveraging its decentralized exchange capabilities for token swaps.
Arbitrum One core contracts
The contract acts as the trusted endpoint for receiving messages from L1 via LayerZero. Its primary role is to securely handle incoming data about MOR rewards sent from L1Sender. Once a valid message is received, the contract processes the payload and execute the token minting logic. It ensures seamless and verifiable communication between the two chains, preserving trust and synchronization of reward distribution.
The contract responsible for handling inbound token transfers from L1, specifically the yield earned in stETH. This contract works in tandem with Arbitrum Bridge to securely receive cross-chain token bridged assets. Once received, these assets (typically wstETH) can be swapped or utilized within the L2 environment—for example, converted into MOR tokens and added to liquidity pools like Uniswap to support the protocol’s token economy. It serves as a bridge landing point for real yield, enabling efficient liquidity flow into the L2 network.
Libs
LinearDistributionIntervalDecrease
This library manages the linear emission decay mechanism used to gradually reduce the amount of tokens distributed over time. It defines how the available reward amount decreases with each interval (e.g., daily, weekly), allowing the protocol to implement a predictable emission schedule. Used by the DistributionV5 contract to calculate how many MOR tokens can currently be distributed based on the time elapsed since the start of the distribution schedule.
LockMultiplierMath
This library provides logic to compute multipliers based on how long a user locks their staked tokens (stETH). The longer the lock duration, the higher the multiplier — encouraging users to stake for longer periods and reinforcing long-term alignment with the protocol.
LogExpMath
Provides high-precision mathematical functions for logarithmic and exponential operations, which are crucial in many DeFi reward calculations (e.g., bonding curves, APY adjustments, dynamic pricing). Solidity lacks native high-precision log/exp functions, so this library ensures safe and accurate computations.
ReferrerLib
Implements referral program logic, enabling the protocol to reward stakers for inviting others. It tracks referral relationships, determines the eligibility of rewards.
Periphery
Uniswap V3
Used to manage MOR token liquidity on Arbitrum. These contracts allow the protocol to add/remove liquidity, perform swaps, and rebalance pools efficiently.
Used contracts:
SwapRouter- facilitates MOR/ETH or MOR/stETH token swaps (and vice versa) within the Uniswap V3 ecosystem.NonfungiblePositionManager- manages liquidity positions represented as NFTs in Uniswap V3.
Links:
Layer Zero V1
Cross-chain messaging protocol used to connect Ethereum (L1) and Arbitrum (L2).
Used contracts:
EndpointV1- acts as the primary messaging interface between L1 and L2.
Links:
Arbitrum Bridge
Used to transfer native or ERC-20 tokens between Ethereum and Arbitrum.
Used contracts:
L1GatewayRouter- sends token bridging instructions from Ethereum.L2GatewayRouter- receives tokens on Arbitrum and finalizes transfer.
Links:
ChainLink
Used to fetch reliable and up-to-date price feeds for each supported staking token.
Used contracts:
EACAggregatorProxy- the contract uses to receive latest price feeds.
Links:
Aave
Used to generate yield from stakes deposited into the DepositPools.
Used contracts:
Pool- the primary contract responsible for handling deposits, withdrawals, borrowing, repayments, and liquidation actions within the Aave protocol. It manages liquidity pools, calculates interest, and maintains reserves.AaveProtocolDataProvider- a utility contract providing comprehensive data about reserve tokens, user positions, and protocol metrics. It enables fetching reserve configurations, token addresses, user account data, current borrowing/deposit rates, and other vital information from the protocol.
Links:
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:
Last updated
Was this helpful?