The Stack brand was created as an idea with some meme potential for a CDP in the levered, high-risk corner of DeFi.
Stack v1 and MORE failed, they’re cooked. But the similarities between the restaurant world and DeFi are maybe more appropriate than ever.
DeFi and great cooking both look to push the boundaries of their space, bringing various ingredients together in creative ways to make something amazing, a brand new experience. Great cooking takes time, trial and error, and often failure before magic is finally made. And even with incredible food, restaurants aren’t guaranteed to succeed.
The same is true for DeFi, where trial, error and innovation often result in failure before they finally lead to success. Stack experimented with new DeFi recipes and new ingredients, ultimately failing to produce an outcome of consequential value.
So where does Stack go from here? A tremendous amount of time and resources have been invested into Stack’s exceptional build quality over the past year. Stack is an asset. Our challenge is to fully utilize it, with a plan to keep cooking and a vision for success.
Stack v2 will open with new management in place and the plans to build an operating team that’s fully segregated from Pearl and supported by community input, with an uncompromising focus on risk management.
In the back-of-house, new devs and advisors are coming in to support the development of Stack v2. This team will work independently from the team managing Pearl in an effort to remove any conflicts of interest and ensure an operational responsibility to the stable, successful growth of Stack. New advisors will be shared shortly.
This also means new front-of-house staff, with new team representatives focused on the Stack community, supporting users and developing marketing, BD and communications strategies focused on Stack v2.
Lastly, we’re committed to bringing the community into the kitchen, launching a new governance model following the $STACK TGE. We could not have made it to Stack v2 without the support of the community.
When governance deploys, the governance framework for Stack should include:
Adding and removing collaterals
Set base interest rates and/or fee tiers and LTV parameters
Balancing the composition of assets backing the CDP
Minimum debt position
Allocation of protocol interest from veRWA to $STACK
Community signatory on the multisig
We look forward to building a successful protocol aided by strong community influence and active governance.
When Stack relaunches, it will include a risk and operational framework of non-negotiables which must be strictly and transparently adhered to as a critical component to enforcing protocol safety.
Debt Ceilings Capped by LiquidityDebt ceilings will be based on available liquidity, requiring that the entire vault can be fully liquidated for USDC, accounting for fees and slippage. $1.00 in USDC must be available for each dollar added to the debt ceiling of any vault, regardless of collateral type.
Caps on Endemic AssetsCollateral assets native to the re.al ecosystem will have vaults capped at a fixed percentage of total mUSD supply. The team will set the initial limits which will be confirmed or shifted at a later date based on governance input.
Signatory AccountabilitySigners on the multisig will be expected to independently verify that the security framework requirements are met prior to approving multisig transactions. This includes checking that there is enough liquidity to handle increases to the debt ceiling and asset caps are below the limit. No more “rubber-stamping” of approvals, regardless of who initiated the transaction.
Full TransparencyThe protocol will issue a monthly audit of the protocol’s health followed by an AMA with the team to address any concerns. Stack will be fully transparent on what the protocol is borrowing and with which assets.
No Secret MenusUnder Stack’s new management, users, team and protocols all eat off the same menu. New vaults and increases to debt limits will be clearly telegraphed in advance so that all market participants have the ability to fairly participate in the ecosystem.
Stack v2 will include a native deployment to Sonic, where we plan to emphasize future growth. Stack will benefit from the flourishing DeFi ecosystem on Sonic as well as the robust incentive program being offered to support growth on the chain.
Using LayerZero OFTs to support core protocol assets will allow Stack to operate in a native capacity on Sonic while still maintaining its presence on re.al.
While Stack’s previous menu items may have been right, the recipes were wrong. Stack v2 will cook up some of the same familiar dishes, but with new, better ingredients.
Stack v2 vaults will still allow users to mint a CDP from deposited assets. However, the v2 vaults integrate a variety of new features to ensure borrowing is much better managed and that users with an appetite for higher risk are paying for their expensive tastes.
New vault positions will be evaluated based on two key criteria:
How much of the CDP the user is minting based on the current debt ceiling for that vault
The collateralization ratio of the position, how much collateral is deposited and how much of the CDP is minted
A risk score will be assigned to each vault position, acting as a multiplier on the base rate. The higher the score, the more interest is paid by the borrower. Instead of simply looking at the deposited asset to determine the rate, the protocol will look at both the asset and the individual position to determine a risk adjusted rate for the borrow.
If a borrower chooses to take out a position representing an outsized percentage of the available CDP liquidity, that borrower (user or protocol) will be forced to pay a fair, risk-adjusted fee on that position.
The risk-managed vaults are a code-based risk management tool that work complementary to the risk management parameters outlined above, implemented and managed by the team multisig and eventual governance.
The original Peg Stability Module (PSM), was a good idea with a flawed implementation.
In short, the PSM was designed to maintain the price stability of the CDP, ensuring it remained as close to the $1.00 soft peg as possible. This was achieved by allowing users to mint the CDP using USDC when the price was stable and redeem when the CDP was below peg, using buy pressure from redeemers to support the price. The PSM also minted CDP tokens to pair with USDC reserves to deepen liquidity.
In reality, the previous PSM design didn’t adequately support peg stability on the downside, rather the redemption mechanism inefficiently gave away capital, exacerbating the bank run.
The new PSM improves on the old implementation in a manner we believe will actually work to support the price and mitigate future depegs.
PSM: 0x1619F51196B33B4B294Ce071F20620467B7aDe78
The PSM allows minting when both the TWAP and spot price of the CDP are above a
predefined threshold (typically set at $1.00). A configurable fee (in basis points) is applied to each minting transaction. The fee is currently set to zero.
The PSM however DOES NOT allow redemptions as we’ve seen they do not contribute to stability. Instead, the PSM manages an automated buy and burn mechanism to stabilize the CDP during downwards trends, reducing supply and supporting the price.
Buybacks are triggered when the spot price is below the TWAP price, indicating a downward trend and the TWAP price is below the buyback price threshold, initially configured to $0.99. The PSM will buy and burn in small increments, never pushing the spot price above $1.00.
The PSM will continue buybacks as long as the spot price remains below the mint price threshold (e.g., $1.00) and the PSM holds sufficient funds to continue operations. Buybacks will be scheduled on a minimum time internal, approximately every 60 seconds, to prevent rapid consecutive buybacks.
The PSM is not designed to be solely responsible for re-pegging the CDP. Instead, its role is to slow down the depeg, while also allowing market participants ample opportunity to purchase the CDP at a discounted price to close their positions. This automated strategy ensures that protocol funds are used effectively, focusing on periods when the token needs support without manual intervention, promoting efficiency and timeliness.
The new PSM does not mint the CDP tokens to pair with PSM USDC to add liquidity. Every CDP token should be fully backed, liquidity should not be manufactured by the PSM.
mUSD is the CDP token for Stack v2. mUSD will be deployed with a new contract, new rules and a new chart. We’re learning from the past while also making a clean break in order to foster an environment of future success for our users and community.
mUSD: 0xe7F144ED68DF10D097931bdC5A691441c1510f37
mUSD has already been deployed to Arbitrum, Base and BSC with the same address as on re.al. And LayerZero has been configured for all possible bridge-paths.
Where mUSD differs from past iterations of the CDP is in the cross-chain design. mUSD can only be minted on re.al. When bridged to another chain, the tokens from re.al are held by the mUSD token contract and minted in the other chain. When bridged back to re.al, tokens are burned on the other chain and then released by the mUSD contract on re.al. This means the total supply on re.al equals the total cross chain supply, making it easier to account for the total supply of mUSD.
Staked mUSD (smUSD) also includes some important new upgrades.
smUSD now accrues yield on a block-by-block basis, eliminating some of the exploits users attempted to double-dip on staking and farming yields.
smUSD also includes an integrated insurance fund where 10% of the staking yield is retained by the protocol to be used for emergency situations. The strategy for how these funds are allocated is still in development.
As part of the Stack v2 rollout, the plan is to slowly build cross-chain liquidity for mUSD that has been minted through the PSM. This includes specific efforts to build liquidity on Sonic as part of our native deployment to that chain.
As of December 4th, mUSD can be minted using the PSM by depositing USDC. This helps kickstart the flywheel through two key functions.
Funding the PSM helps ensure depeg mitigation funds are available at the protocol’s launch.
Building cross-chain liquidity for mUSD to ensure the rollout of Stack v2 is as unblocked as possible by liquidity constraints.
mUSD pools will be available on various DEXs with the plan to incentivize them on a weekly basis from now until redeployment.
Details have been previously shared on the $STACK token, which will TGE at some time in Q1 2025. 50% of the $STACK supply will be allocated to users impacted by the failure of Stack v1 CDP.
In addition to the governance benefits outlined above, $STACK holders will also accrue revenue generated by the protocol. The team is currently exploring ways by which we can accrue value for $STACK holders prior to TGE.
We’re continuing to build Stack v2 and the process is evolving as we work through the details. We’ll do our best to adhere to the roadmap above and any deviations will be shared with the community.
We’re committed to investing in Stack, building an exceptional product and returning value back to the community of users that has supported us 🍔