Hello,
This is a proposal for a crosschain Transmuter deployment for USDA.
In this proposal we do not only explain the rationale for this crosschain Transmuter deployment but we also go into the details of the infrastructure we’d use for this.
Context
Making stUSD easily accessible to anyone on any chain
Right now, USDA can only be minted natively on mainnet from USDC, bIB01 and steakUSDC.
There are other issuance mechanisms, notably the lending and liquidity AMOs of the protocol, but all of these remain bound to mainnet.
Typically, someone looking to get USDA on Arbitrum needs to mint USDA on Ethereum and bridge with our LayerZero infrastructure.
In the current setup, the promise of offering through stUSD a savings account 2.0 easily accessible by anyone with no fees onchain is limited by the liquidity on the secondary market. On Base for instance, people have to face a 20bp slippage for every 10k USDC->USDA swap.
Building a source of apparent liquidity for anyone to get into stUSD with $1 or $1m at the same cost is key in promoting stUSD as the most liquid, resilient and scalable source of yield onchain.
In an ideal world, stUSD is this product where you can get in, or out instantly at any time without having to fear for entry or exit slippage and while still providing guarantees on what happens if there is a black swan event on one of the assets that the protocol uses to generate yield (or for users to get in/out)
In fact making stUSD liquid and easily available at scale goes beyond the idea of powering a new form of savings account, it’ll enable the abstraction of stUSD yield derived from mainnet, making it open to everyone, even those who do not have enough funds to pay Ethereum gas fees.
Transmuter advantages and limitations
Transmuter is the most resilient price stability mechanism ever designed for a stablecoin. It can track when something is going off in its reserves and automatically fallback into modes that preserve its stakeholders (=stablecoin holders) from “bad” situations like bank runs.
The thing is that Transmuter works in isolation and only accounts for its “own” balance sheet.
Typically if a Transmuter is deployed on Arbitrum, the Ethereum Transmuter wouldn’t be aware of the state of the reserves of the Arbitrum Transmuter. Something could go off on Arbitrum and the Ethereum deployment wouldn’t automatically fallback on its mode to freeze its collateral exposures.
Asset liability management is easy to handle automatically onchain when it’s just for one module on one chain, it’s impossible to have a fully trustless system for it when the balance sheet of the protocol is spread out on multiple chains across multiple independent contracts which only have in common the right to mint the same stablecoin.
Making the best of liquidity and security
Deploying Transmuter implementations therefore brings some additional risk and reduces some of the guarantees that you have with a single Transmuter. Yet it also unlocks a huge liquidity advantage (e.g minting a virtually unlimited amount of USDA with USDC with no slippage).
It’s about balancing out what’s gained here with the security implications.
The important parameter in every Transmuter deployment is the max exposure that the system has to each collateral asset. Transmuter doesn’t implement absolute debt ceilings for each asset in its backing, rather it has relative exposures based on the exposures the system has to the other collateral assets supported.
What we propose here is to deploy a modified Transmuter implementation with an absolute debt ceiling on the amount of stablecoins that can be minted in total. This way, the protocol can still control to some extent the maximum exposure it can have to USDC in the backing and put itself in a position where it’d lose less if USDC was to depeg again, just like it did in March 2023 or that would protect more users all in all.
With this, the protocol can strictly cap the USDA that can be minted from its USDC Transmuter to like 5m USDA in total.
Dealing with rebalancing
How would this all take shape in practice?
Starting with this Transmuter implementation, let’s say now that a Transmuter is deployed on Base on top of the Ethereum deployment. What if someone comes to mint 2m USDA on Base with 2m USDC.
The protocol would still need to find a way to earn a yield on a portion of these 2m USDC, otherwise the stUSD yield would rapidly decrease.
The goal of the protocol is to optimize its balance sheet under liquidity and solvency constraints. With new crosschain Transmuter deployments, protocol need to be wary of optimizing between the two following logic:
- optimizing for the yield so it can still afford to pay stablecoin holders in stUSD
- ensuring sufficient exit liquidity is here for people who minted USDA from USDC on the chain. While with the deployment on Base, anyone will be able to mint, if the protocol automatically goes to find yield somewhere else with the USDC that were deposited, then there may be some situations where someone who minted USDA with USDC on Base wouldn’t be able to get USDC back from its initial investment (because everything is elsewhere)
In the setup we propose, the yield generated is still to be earned on mainnet. And the reserve allocation targeted by the protocol should remain the same. The protocol should still make sure to keep a sufficient liquidity buffer on Base for this.
How to fetch yield on mainnet and respect the allocation breakdown (between USDC, steakUSDC and bIB01) when USDC are held on Arbitrum?
We propose to introduce a rebalancing AMO, under the form of a bot, with pre-minted USDA and that would be powered by an offchain engine reading into the protocol exposures across all different chains and bridging liquidity from one chain to another (sometimes repeatedly) to bring exposures on every chain back to their target.
Let’s take 2 different cases to show how this would work
1st setting: Earning yield
Protocol has $10m TVL on Ethereum, and is at target exposures (15% USDC, 25% bIB01, 60% steakUSDC). And 5m USDA are minted on Base from 5m USDC. What the rebalancing AMO would do in this case is the following:
- it’d burn the pre-minted USDA it controls for USDC on Base
- bridge a portion of the the USDC to Ethereum (computed to leave 15% of the 5m USDC held on the chain)
- mint USDA from the USDC on Ethereum and hereby trigger a rebalancing of the Transmuter reserves so Transmuter tries to acquire with it bIB01 with 25/85 of the USDC bridged back and steakUSDC with 60/85 of the USDC bridged back
- bridge back the USDA on the chain of interest
Depending on the size of the position, the rebalancing AMO could run this operation several times successively. The gas cost for conducting this would therefore be inversely proportional with the size of the AMO. Assuming an AMO of size 100k and 4m USDC to rebalance, it’d take 40 runs to rebalance everything.
The size of the AMO is to be calibered with:
- the size of the protocol and its equity
- the size to expect for such rebalancings
2nd setting: releasing liquidity
Assume 1m USDC is left on Base and someone comes to burn 500k USDA for 500k USDC. The protocol needs to bring back more USDC and re-build the USDC liquidity buffer. Here’s how it’ll go:
- the AMO would burn USDA for USDC on mainnet
- bridge the USDC to Base
- And mint USDA with USDC on Base
Technically any well funded address could engage into this rebalancing arbitrage. Yet, in the current setup there would be no immediate profit for doing so (we’re still looking how to setup an incentive system to arrive to this goal). On top of this, as it stands the cost of liquidity to do this with a market maker would outweigh the one with having the funds on an EOA in an independent infrastructure.
We therefore suggest as a starter to begin with an AMO of 100k USDA in size in order to limit the risk the protocol would take. The keeper is to be delegated to an infrastructure run by Angle Labs as trusted provider in that respect.
Proposal
The exact proposal is as follows:
- deploy a modified version of the Transmuter with a debt ceiling on Arbitrum and Base accepting USDC as a collateral. Debt ceiling can be updated by the guardian address of the protocol and should be set in order to ensure that no more USDC are minted on these other chains than what has been minted on Ethereum
- fund the rebalancing AMO with 100k pre-minted USDA (there are already pre-minted USDA available on the protocol treasury address for USDA) and transfer them to the rebalancing bot address
Considerations
This setup has been all in all designed to enable anyone to get access to stUSD yield easily, with size (without being bound by secondary market liquidity) and with no fees onchain while:
- ensuring that the main trust assumptions that the Transmuter brings are not compromised
- maximizing as much as possible the trustlessness of the setup by only granting a small amount of funds to the rebalancing address and an amount that’s less than 1/30th of the protocol equity for USDA
- guaranteeing that the protocol is still able to earn a yield even when people come to mint on other chains with non-yielding USDC
- optimizing for everyone’s exit liquidity meaning that people minting should also have most of the time enough liquidity to exit when they want. By the way it’s worth noting that if the Transmuter reserves have been depleted on a chain, people will still be able to bridge back from this chain and get access to the main USDC reserves
Upon deployment, there will be a build up phase where people can come and mint USDA from USDC on these chains and the protocol fills up its reserves. Precisely, right after deployment, people who have USDA/stUSD on Base won’t be able to burn their USDA for USDC on the chain (because there would be no reserves for this), but people looking to mint more USDA from USDC with no fees will be able to do so.
The 100k limit for the rebalancing AMO has been done to cap the overall risk within acceptable bounds (relative to the total equity in the protocol).
Down the line and based on our first iterations, we could:
- increase the size of this AMO for rebalancing
- work on smart contracts to make rebalancing more permissionless. This could for instance take the form of contracts being plugged on Circle CCIP solution to support bridging.
As always, feel free to let us know your thoughts on the overall design here!