Stablecoins on Miden using Asset Accounts

[Dominik1999]

Summary

On Miden we need to provide stablecoins. We cannot deploy ERC20 contracts on Miden. We can mimic most of the features also in Miden Token Accounts. The main problem might be how to handle the case if an address is being blacklisted on Ethereum but has already bridged stablecoins to Miden.

---

Miden needs stablecoins for DeFi

DeFi is one of the most widespread use case categories on blockchains, especially on Ethereum. Stablecoins drive DeFi. If Miden wants to become a relevant smart contract blockchain, it should provide the ability for stablecoins.

In theory, Miden enables all existing stablecoin projects to launch their stablecoin on the platform. The projects have already gained the user's trust and have ways to deal with the regulators. But it is also possible for Polygon to launch its stablecoin on Miden.

Existing stablecoins use ERC-20 (or similar) token contracts

The most used stablecoins are smart contracts following the ERC-20 token contract standard (or the BEP-20 on Binance), see USDC, USDT, DAI, WeTH, BUSD. Those token contracts can be transferred onto other EVM-like blockchains, but not so easy to systems like Miden.

Stablecoins differ in the way how they keep a stable value. Fiat or Collateral backed stable coins like USDT or USDC might be easier to rebuild on Miden than stablecoins with more complex stability mechanisms like DAI.

In Miden, there are no token contracts but token accounts

In Miden, there are Asset accounts that issue assets; see 0xPolygonMiden/miden-vm#339.

EXAMPLE: Ways to rebuild (fiat-backed, centralized stablecoins) USDC on Miden

Let's collect some ideas on how to provide USDC on Miden to Miden users.

There are other stablecoins and projects. I picked USDC as an example because it is the most used stablecoin by far - https://dune.com/hagaetc/stablecoins.

Some background on USDC:

• USD Coin (USDC) is a cryptocurrency designed to maintain a constant value of $1 USD.
• Each USDC is redeemable for one dollar and is backed by one dollar or a dollar-denominated asset with the equivalent value held in accounts at regulated U.S. financial institutions.
• USDC first launched on the Ethereum blockchain as an ERC-20 token, but has since expanded to other blockchains, including Solana, Stellar, and Algorand.
• USD Coin is managed by a consortium called Centre, which Circle and Coinbase founded

Some ideas on how to rebuild the features

There are two ways for USDC to be deployed on Miden:

Mint and release

Other rollups, optimistic or zk, mint tokens on the rollup when those tokens are deposited on the Ethereum side of the token bridge. Those tokens get burnt whenever a user wants to bridge the tokens back.

In theory, there can be a USDC Asset account issuing as many USDC as there are in the rollup token bridge on Ethereum. On Asset accounts, one can set and change the admin, who can have the ability to mint more. Also, the query of the total supply should be an easy thing to do.

Native USDC

Circle wants to release native implementations of their tokens also on Rollups. The difference might be (it is not clear yet) that Circle has control of the token contract and can blacklist users and issue tokens.

Let's try to continue with the easier Mint and release approach. Easier because we don't need to align with Circle on how to implement that token.

Necessary features for USDC:

For reference, the USDC smart contract (https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code)

• Upgradeability - allows to change the implementation address to which it will delegate
• Set / Change Admin - Contract combines an upgradeability proxy with an authorization mechanism for administrative tasks.
• isMinter - checks if the address can issue new tokens
• totalSupply - returns total supply on that chain
• balanceOf - returns the balance of an address
• isBlacklisted - lists addresses that cannot move tokens anymore; there is also a blacklister who can define addresses to be blacklisted

There might be more necessary features. From the listed features, the most problematic features seem to be to get the balance of some other user and to blacklist someone. Assets are stored in the accounts directly - there is no global list. And in Miden, it is possible to hold account data off-chain.

Getting the balance of a user balanceOf

1. We could say that if a user uses USDC, she/he cannot store the account information off-chain. Not a very elegant solution, e.g. it would be unnecessarily expensive to use USDC compared to other assets.
2. Users could get queried directly, and they could provide a proof that their USDC balance is above a certain amount. For most use cases, where smart contracts or other users need to check the balance of a certain account, that should work.
3. ...

Blacklisting a user isBlacklisted

Since USDC is a centralized stablecoin - partly regulated under the SEC - there must be the ability to prevent users from using USDC (e.g. money laundering).

1. All USDC payments could always return to the USDC Asset account that automatically sends the asset to the specified receiver. That way, the USDC Asset Account could still have a blacklist. But users on Miden would sacrifice some features to be able to use USDC
2. In theory, it might be enough to rely on the blacklisting feature of the USDC contract on Ethereum. There are two possible cases of blacklisting:
   2.1) An address is already blacklisted and tries to bridge to Miden: The bridging transaction on Ethereum will fail.
   2.2) An address bridges to Miden and gets blacklisted on Ethereum afterwards: The user can use the USDC tokens issued on Miden and potentially swap those. The user cannot get USDC out of Miden because that transaction would happen on Ethereum. However, the tokens can be swapped against other tokens on which the user is not blacklisted. It is unclear how other rollups / sidechains handle that case.
3. ...

[bobbinth]

I think I'd separate these into several categories. Specifically, I think there is a difference between bridged stable coins and native ones. Supporting bridged coins might be much easier than native ones. Similarly, I think there is a difference between centralized and algorithmic stable coins. For example, supporting DAI might be easier than USDC. So, I think we should evaluate each of these separately.

If we are talking about bridged USDC, would be great to learn more about how current implementations work. For example, how is it ensured that blacklists are updated on all bridged assets.

[Dominik1999]

Those are very good points.

We can differentiate stablecoins using the underlying collateral - fiat-backed, crypto-backed and commodity-backed. And we can analyse how each type can be implemented in Miden, either being bridged (minted by the project behind it or minted by us) or implemented directly. And we should consider which stablecoin is used most across the chains - so we can ignore commodity-backed coins for now.

For example, USDC supports some chains directly (e.g. Ethereum and Avalanche). On some chains, non-official contracts simply mint USDC iff they are locked on the canonical bridge (e.g. Polygon, Arbitrum). However, Centre plans to support all chains directly and implement official contracts there. Also, they want to introduce their bridging protocol - Cross-Chain Transfer Protocol.

This is similar to MakerDAO and DAI. Also, they plan to have a canonical bridge.

	Fiat-backed	Crypto-backed	Commodity-backed
Bridged (canocial minting)	A	D	not used much
Bridged (minted by bridges)	B	E	not used much
Native	C	F	not used much

Let's first go for the easiest to implement stablecoin in the analysis.

Most used stablecoins are fiat-backed stablecoins - USDC and USDT (taken together with their implementations on the respective chains).

In the end, we should provide the features to allow all of the possible implementations.

A) Fiat-backed stablecoin to be minted (and released) by Polygon Miden

Here, we could have an Asset Account that mints tokens when locked on the Ethereum bridge. There would be no involvement of Centre, and there would be no official implementation. We can just call this token Miden USDC (like BSC does that with USDC and USDT). On those copied contracts, there is no blacklisting, and there is no official involvement of the projects behind USDC or USDT. However, I am almost 100% certain that this has some regulatory consequences.

B) Fiat-backed stablecoin to be minted by bridges on Miden

In theory, we can let the bridges that bridge to Miden mint their version of a fiat-backed stablecoin. This is how Multichain bridges assets (one way). They create an AnyUSDC on the target chain and send it to the user. The user can bridge that back. This could be better usability, and someone needs to ensure that users can use AnyUSDC the same way on Miden as they could use USDC on other blockchains, e.g. exchange it on a DEX and use it as collateral.

C) Fiat-backed stablecoin native on Miden

This is how Centre and other projects want to have it. We can contact them and ask what they need to be able to implement their version of USDC or USDT on Miden.

A) and C) are reflected in the discussion point above. However, in A), we are more flexible in not implementing every feature.

D) Crypto-backed stablecoin to be minted (and released) by Polygon Miden

This is like in A).

E) Crypto-backed stablecoin to be minted (and released) by Polygon Miden

This is like in B). It might be easier to convince MakerDAO to implement a canonical version on Miden. But we should work on a proposal incl. a technical description on how this could look like.

F) Crypto-backed stablecoin native on Miden

This is a super interesting task and might be a good project for a hackathon. Maybe - given the Miden feature set - we can even offer a better version of DAI on Miden. But I think especially for DAI at the moment they are all "created" and "backed" on Ethereum and only bridged to other chains.