MOR 20 Contracts

This documentation is for an early implementation of the MOR20 smart contracts, subject to change. Before conducting a Fair Launch, consider coordinating with other contributors in the MOR20 chat in the Morpheus Discord.

MOR20 is a standardized implementation of the Morpheus Techno Capital Machine that can be used to fairly launch new projects while ensuring alignment with the Morpheus ethos and its community.

As in the case of Morpheus itself, a MOR20 token launch consists of an omnichain ERC20 token (Arbitrum, Ethereum, Base), utilizing LayerZero's OFT token standard, as well as an Ethereum staking contract for Capital Providers (stETH) on Layer 1 (Ethereum). Additional helper contracts are used for cross-chain communication and rewards calculation. Projects that launch using MOR20 can use other chain combinations.

This design enables a fair token distribution among Capital providers (and other ecosystem participants), with yield from staked Ethereum used to create Protocol-Owned Liquidity.

Contracts Architecture

A MOR20 deployment consists of the following contracts:

  • ERC20MOR – the project's reward token

  • Distribution – used to lock capital for the Techno Capital Machine and claim rewards

  • LinearDistributionIntervalDecrease – a library for calculating rewards

  • L1Sender – sends MOR minting requests; wraps and transfers stETH to L2

  • L2MessageReceiver – receives and processes MOR minting requests on L2

  • L2TokenReceiverV2 – receives wstETH and manages Protocol-Owned Liquidity on L2

These contracts are functionally equivalent to those used by the Morpheus token itself.

Contracts Deployment

MOR20 contracts are deployed using the Mor20FactoryL1 and Mor20FactoryL2 factory contracts:

  • deployMor20OnL1 on Mor20FactoryL1 deploys the Distribution and L1Sender contracts.

  • deployMor20OnL2 on Mor20FactoryL2 deploys the ERC20MOR (the project's reward token), L2MessageReceiver, and L2TokenReceiver contracts.

These methods can be called in any order; however, before calling either method, the deployer should know the counterfactual deployment addresses of the second method, which can be calculated using predictMor20Address.

You can find the full guidance on Github or ask your questions in Discord.

Last updated

Was this helpful?