Mountain Protocol
  • Getting Started
  • USDM Wind-Down Overview
  • Reference
    • USDM Token
    • Product Structuring
    • Mountain Protocol Platform
    • USDM Reserves
    • USDM Reserves - Attestations
    • USDM Reserves - Investment mandate
    • Risks
    • API Overview
    • Security resources
    • Official media accounts
  • Legal
    • Terms and Conditions
    • Terms and Conditions - Phase 3
    • U.S. Restrictions
    • Data Privacy Policy
Powered by GitBook
On this page
  • USDM contract overview
  • Rebasing example
  • How the rewardMultiplier works
  • Other notable function mentions
  • Dependencies
  • Resources
  • Access control roles
  • wUSDM
  1. Reference

USDM Token

PreviousUSDM Wind-Down OverviewNextProduct Structuring

Last updated 2 months ago

The is an ERC20 rebasing token, with a redemption value pegged at 1:1 for primary customers. Like other fiat-backed stablecoins, we expect a 1:~1 in secondary market price, driven by arbitrage opportunities.

For more details about rights related to USDM, please visit .

USDM contract overview

USDM is built on top of the OpenZeppelin implementation, adding rebasing dynamics to the contract, following the same "share of total supply" pattern as .

The rebasing mechanism is implemented via the "shares" concept. Instead of storing a map with account balances, the USDM smart contract stores which "share" of the total pool is owned by the account. The balance of an account is calculated as follows:

balanceOf(account) = shares[account] * rewardMultiplier

shares - map of account share of the total supply. Every time USDM is minted or burnt, it is converted to shares and added/deducted and assigned to user's balance.

rewardMultiplier - is the sum of daily addRewardMultiplier, accruing daily for users.

Rebasing example

If a user purchased 100 USDM when the rewardMultiplier was 1.00, that user would receive 100 shares of USDM. If the average APY for the year stayed constant at 3.8%, that user would now have 103.8 USDM. Below is an example of the USDM balances, shares, and rewardMultiplier:

Time
USDM (balanceOf)
Shares
rewardsMultiplier

Day 0

100

100

1

Day 365

103.8

100

1.038

If this user wanted to redeem 100 of the 103.8 USDM, they could transfer 100 USDM to their Mountain Protocol account, via the Platform.

Under the hood, the contract will transfer 100/1.038 = 96.339 shares

In this example, the user will receive $100 for their 100 USDM and keep 3.8 USDM.

How the rewardMultiplier works

The rewardMultiplier variable is updated daily, at or around 12pm UTC, by calling the addRewardMultiplier function applying the daily yield, changing the value of the rewardMultiplier.

Below is an example of how the rewardMultiplier and the addRewardMultiplier work together (note that USDM contract runs on an 18-digit standard, but those have been simplified for this example). The rewardMultiplier starts at one and is increased by the addRewardMultiplier function on a daily basis.

The column shows the value of the rewardMultiplier sent to the addRewardMultiplier function and the resulting ongoing state of rewardMultiplier.

Day
rewardMultiplier
addRewardMultiplier

0

1

0.000080986

1

1.000080986

0.000080993

2

1.000161979

0.000081000

3

1.000242979

0.000081006

4

1.000323985

0.000081012

5

1.000404997

6

...

Other notable function mentions

  • transfer: The transfer function works like any other ERC20. Note that the transferred amount will be USDM, not shares. This will match the user expected behavior, by sending balanceOf and not Shares.

  • totalShares: This function returns the total number of shares in circulation. Note that this number will be different from the total USDM in circulation, as this does not account for the yield component embedded in the rewardMultiplier.

  • totalSupply: This function returns the total number of USDM in circulation. totalSupply is calculated by applying the rewardMultiplier to the totalShares.

Dependencies

The USDM contract builds its foundation on top of OpenZeppelin Contracts library, widely used and recognized battle-tested components throughout the Ethereum ecosystem:

  • AccessControlUpgradeable.sol

  • PausableUpgradeable.sol

  • UUPSUpgradeable.sol

  • CountersUpgradeable.sol

  • ECDSAUpgradeable.sol

  • EIP712Upgradeable.sol

  • IERC20PermitUpgradeable.sol

  • IERC20MetadataUpgradeable.sol

Resources

Explore the following essential resources to gain a comprehensive understanding of USDM Token and its associated network:

  • USDM Token Addresses:

  • wUSDM Token Addresses:

Access control roles

Below you will find the access control roles and their corresponding addresses for USDM. Each role is linked to a specific set of permissions that are associated with it.

  • MINTER_ROLE: Grants the ability to mint tokens.

    0x48AEB395FB0E4ff8433e9f2fa6E0579838d33B62

  • BURNER_ROLE: Grants the ability to burn tokens.

    0x48AEB395FB0E4ff8433e9f2fa6E0579838d33B62

  • BLOCKLIST_ROLE: Grants the ability to manage the blocklist.

    0xB4d98351418c3d35195406e114E56B068F876c8f

  • ORACLE_ROLE: Grants the ability to update the reward multiplier.

    0xD20D492bC338ab234E6970C4B15178bcD429c01C

  • PAUSE_ROLE: Grants the ability to pause/unpause the contract.

    0x16d72b58B8A0bBCf3A6751920ef127Fe746a3BB0

  • UPGRADE_ROLE: Grants the ability to upgrade the contract.

    Not assigned

  • DEFAULT_ADMIN_ROLE: Grants the ability to grant or revoke roles.

    0x313d5B7EfDcd84e8a52D425282B03860e9354d74

wUSDM

To solve this problem and ensure USDM holders have full compatibility with DeFi without giving up their rewards, the Mountain Protocol team has built and made permissionlessly available a wrapper on USDM which is called wUSDM. Such wrapper is very similar to Lido's wstETH, a product that is already familiar to the digital asset ecosystem.

rewardMultiplier: Allows developers to read the cumulative yield accrued since the beginning of the contract. Note that past does not predict future. The is usually a better proxy to USDM yield than historic values.

Open Source Code:

Bug Bounty Program:

Audit Reports:

Security Center by OpenZeppelin:

Security Policy:

License:

Smart Contract Code Coverage:

Documentation:

Ethereum:

Arbitrum:

Base:

Optimism:

Polygon:

Avalanche:

Celo:

ZKSync Era:

Ethereum:

Arbitrum:

Base:

Optimism:

Polygon:

Avalanche:

Celo:

ZKSync Era:

Acknowledging the complexities of handling rebasing tokens in the DeFi ecosystem, the contract serves as a wrapped token, simplifying integration while preserving stability.

The wUSDM contract is an ERC-4626 (following the , leveraging the ), enabling users to deposit USDM in exchange for wUSDM tokens. The USDM tokens are rebasing, whereas the wUSDM tokens are non-rebasing, making wUSDM easier to integrate in DeFi protocols.

Rebasing tokens have known integration challenges with protocols that assume constant balanceOf for tokens (such as Uniswap, 1Inch and Sushiswap). This can lead to daily rewards being captured by players other than the USDM holders in protocols. The stETH issuer, Lido, has .

USDM Token
Rights of USDM holders
ERC20 canonical
Lido's stETH
Secured Overnight Funding Rate
https://github.com/mountainprotocol/
https://immunefi.com/bounty/mountainprotocol/
https://github.com/mountainprotocol/audits
https://security.mountainprotocol.com/
https://github.com/mountainprotocol/tokens/blob/main/SECURITY.md
https://github.com/mountainprotocol/tokens/blob/main/LICENSE
https://app.codecov.io/github/mountainprotocol/tokens
https://docs.mountainprotocol.com/
https://etherscan.io/token/0x59D9356E565Ab3A36dD77763Fc0d87fEaf85508C
https://arbiscan.io/token/0x59D9356E565Ab3A36dD77763Fc0d87fEaf85508C
https://basescan.org/token/0x59D9356E565Ab3A36dD77763Fc0d87fEaf85508C
https://optimistic.etherscan.io/token/0x59D9356E565Ab3A36dD77763Fc0d87fEaf85508C
https://polygonscan.com/token/0x59D9356E565Ab3A36dD77763Fc0d87fEaf85508C
https://snowtrace.io/token/0x59D9356E565Ab3A36dD77763Fc0d87fEaf85508C
https://celoscan.io/token/0x59D9356E565Ab3A36dD77763Fc0d87fEaf85508C
https://era.zksync.network/token/0x7715c206a14ac93cb1a6c0316a6e5f8ad7c9dc31
https://etherscan.io/token/0x57F5E098CaD7A3D1Eed53991D4d66C45C9AF7812
https://arbiscan.io/token/0x57F5E098CaD7A3D1Eed53991D4d66C45C9AF7812
https://basescan.org/token/0x57f5e098cad7a3d1eed53991d4d66c45c9af7812
https://optimistic.etherscan.io/token/0x57f5e098cad7a3d1eed53991d4d66c45c9af7812
https://polygonscan.com/token/0x57f5e098cad7a3d1eed53991d4d66c45c9af7812
https://snowtrace.io/token/0x57f5e098cad7a3d1eed53991d4d66c45c9af7812
https://celoscan.io/token/0x57f5e098cad7a3d1eed53991d4d66c45c9af7812
https://era.zksync.network/token/0xa900cbe7739c96d2b153a273953620a701d5442b
wUSDM
tokenized vault standard
OpenZeppelin implementation
documented this phenomenon here