Summary

Sky is a stablecoin protocol allowing users to mint its USDS stablecoin through Collateralized Debt Positions with a variety of crypto collateral assets. Sky is built on the Maker protocol, by the MakerDAO, to replace the DAI stablecoin and allow for the 1:1 conversion between DAI and USDS. USDS can further be staked for the yield-bearing sUSDS token. Various levels of control over the Sky protocol are exercised through an onchain governance system.

Ratings

Chain

This review focuses on the Ethereum instance of Sky. Ethereum achieves a Low centralization risk score.

Chain score: Low

Upgradeability

USDS and sUSDS, Sky's stablecoin and its corresponding yield-bearing version, are upgradeable contracts through Sky Governance proposals. Updating those contracts could change the entire logic of those tokens and may incur a loss of funds for users.

Critical parameters in the Sky protocol can be changed through Sky Governance proposals. Unwanted updates to these parameters can result in the loss of funds, loss of unclaimed yield, or otherwise materially impact the expected protocol performance. Example actions are forced liquidations, which would result in loss of user funds, creating unbacked debt, which could endanger the protocol's stability, or pausing the contracts, which could trap user funds for an undetermined amount of time.

Upgradeability score: High

Autonomy

Sky has a centralized dependency on Circle and its USDC stablecoin token. This is because users can mint USDS from USDC at a fixed 1:1 rate. This means that USDS is directly pegged to USDC (instead of USD), which is a centralized stablecoin. This conversion may be stopped or paused in an emergency Sky Governance proposal. There is a debt ceiling limiting how much USDS can be backed by USDC. Nonetheless, at the time of writing, this debt ceiling is high enough that it does not prevent more than 50% of the collateral in Sky from being backed by USDC. The ceiling is explained further in the dependencies section.

The Sky protocol also relies on Chronicle's oracle price feeds to assess the solvency of debt positions. The Chronicol protocol uses a system of validators hosted by various third parties such as Bitcoin Suisse, ETHGlobal, Gitcoin, and Etherscan. Validators push price updates onchain. We found that any changes to the validator set are subject to a 7 days exit window. Chronicle thus achieves a Medium centralization risk score as discussed in a separate report here.

An Oracle Security Module (OSM) enforces a 1-hour delay on price updates, and the Sky Governance can freeze the current price to prevent further updates in case of emergency. The price feed provider could be changed through a governance proposal.

Autonomy score: High

Exit Window

All permissions within Sky are held by the onchain Sky Governance. There are no external accounts or multisigs in control.

The Sky Governance is controlled by MKR/SKY token holders who locked their tokens to earn voting power, which allows them to submit and vote on respective proposals, or delegate their votes to another user. Any token holder can create a proposal, and the protocol uses a system of continuous approval, explained in more detail in the governance section.

The minimum delay between approval and execution of a proposal is currently 18 hours. Sky Governance proposals have a recurring weekly and monthly schedule. Those proposals usually have a courtesy delay duration of 2-3 days before taking effect, but proposals remain possible at any time with the minimum delay.

Emergency measures allow the Sky Governance to pause certain contracts through a proposal without being subject to the mandatory delay. In addition to that, an Emergency Shutdown Module (ESM) exists and can irreversibly shutdown the entire protocol if 500'000 MKR tokens are sent to the Emergency Shutdown Contract. Funds sent to the contract are considered lost, no matter the emergency status. During an emergency shutdown, users can retrieve their supplied assets, but no additional supply or borrowing is allowed. This is explained further in the technical governance section.

Exit Window score: High

Accessibility

Sky has a main frontend at sky.money. The frontend is not self-hostable nor open source, but multiple other access points exist with Sky-specific apps such as Spark or third-party apps like DeFiSaver or SummerFi Pro. These apps build an acceptable backup solution in case of failure of the official frontend.

Accessibility score: Low

Conclusion

The Sky protocol exposes critical permissions that are not protected with an Exit Window of at least 7 days or a Security Council and thus earns a High centralization risk score for its Upgradeability and Exit Window dimensions.

Furthermore, Sky is exposed to centralization risks from its USDC and Chronicle dependencies, resulting in an overall High centralization risk score for the Autonomy dimension.

Sky thus achieves a decentralization of Stage 0.

The protocol could reach Stage 1 if it no longer swaps its USDS with Circle's UDSC in a blind fashion and increases its Exit Window to at least 7 days or establish a Security Council. It could further reach Stage 2 with an Exit Window of at least 30 days, and if it changes its oracle provider to a Stage 2 or equivalent protocol. This could also be achieved if Chronicle increases its Exit Window to 30 days.

Overall score: Stage 0

Reviewer Notes

⚠️ During our analysis, we discovered a paradigm of Authority contract used to handle fine-grained permissions over functions and contracts. In most cases, the authority is DSChief and this allows governance proposals to have non-delayed access to certain functions. Nonetheless, this could be misused to grant any arbitrary address those same permissions. We note that because of the lack of events in the DSChief's role granting functions, we had to scan all governance proposals to ensure this has not happened in the past, and would encourage that those functions are blocked in future versions of the governance contract.

Protocol Analysis

Sky Stablecoin Module (CDP)

The contracts related to the Collateralized Debt Module are highlighted below. The Vat is the core accounting system of the protocol and acts as a balance sheet for debt positions against all collaterals. Each collateral needs an adapter contract called Join so that it can be linked to the Vat. A Dog contract monitors the positions and can bark when a position becomes liquidable. It kicks the collateral's Clipper (or LockstakeClipper if the collateral is sealed MKR) and starts the auction process. The Vow is the contract that keeps track of all surplus and debt and is the beneficiary of all the DAI raised in the auction. The Flopper or Flapper is responsible for debt or surplus auctions, respectively. The Vow is the beneficiary of the DAI raised in auctions. It is important to note that the governance has permission on those contracts and could trigger unjustified liquidations by bypassing the Dog contract.

The Spotter feeds the price used for liquidation and auctions. It reads the price out of the OSM (Oracle Security Module), which delays price updates by one hour and can be frozen in case of emergency. Incorrect oracle prices could potentially liquidate the entire Maker ecosystem. The oracle provider Chronicle is, therefore, extremely trusted.

The Pot and Jug contracts represent the rates module. Respectively, the Potcontract allows users to save at a specific DAI Savings rate and the Jug contract handles stability fees. We note that the savings rate is not limited and may become either highly negative or positive under future governance proposals.

As for the governance and tokens, the Mom contracts (FlapperMom, FLopperMom, OSMMom) have the ability to stop their child. The permissions to do so are granted by DSChief, the governance contract, so that governance proposals can stop those contracts without delay.

Sky ↔ Maker Conversion Module

The contracts related to the conversion from legacy Maker tokens to Sky are displayed in the diagram below. Following the Sky End Game Plan, the DAI and MKR have been replaced by USDS and SKY respectively. Conversion contracts allow for the swap from legacy to new tokens and back at a fixed rate. In addition to that, a LitePSM (Peg Stability Module) allows users to swap USDC for USDS with no impact on the peg thanks to pre-attributed reserves.

A LitePSM (Peg Stability Module) allows users to swap other stablecoins for USDS with no impact on the peg, thanks to pre-attributed reserves.

The governance has admin privileges over all contracts and could, for example, arbitrarily mint tokens. DSChief, the (non-delayed) governance contract, is the authority over the LitePSMMom, which allows governance proposals to stop the LitePSM without any delay.

Finally, users can put their USDS into savings and obtain sUSDS. sUDS is the yield-bearing token associated with the ERC4626-compatible sUSDS contract. The value of sUSDS increases at a fixed rate chosen by the Sky Governance. This also allows users to obtain sUSDS tokens through other means, such as swapping using decentralized exchanges.

Sky Rewards

A StakingReward contract allows users to stake USDS and receive SKY as a reward according to an issuance chosen by the governance. Users can stake their USDS directly in the StakingRewards contract and claim their rewards with the same contract. DssVestMintable contracts allow the governance to create vested plans that will gradually mint tokens to distribute to some beneficiaries.

Dependencies

Circle's USDC

USDS is pegged to Circle's USDC rather than USD due to its stability module.

Users can mint USDS from USDC at a fixed 1:1 rate using the LitePSM (Peg Stability Module). This means that USDS is directly pegged to USDC (instead of USD), which is a centralized stablecoin. There is a debt ceiling limiting how much USDS can be backed by USDC. This debt ceiling is dynamic, it can be increased every 12 hours by 400 Mio if the current debt approaches the ceiling (debt + 400 Mio > ceiling). The ceiling can reach up to 10 Billion USDS, making USDC more than a collateral for Sky, but a peg for its stablecoin.

The LitePSM, which allows this conversion, may be stopped or paused in an emergency Sky Governance proposal.

Chronicle

The Sky protocol also relies on the provider Chronicle for price feeds of collateral assets.

Chronicle is an oracle protocol that computes a median price from multiple sources. The protocol contains validators who push new prices and challengers who can freeze and challenge new prices. The validator set of an oracle can be changed with a delay of 7 days. We analysed Chronicle's decentralization in a dedicated report here.

An Oracle Security Module enforces a 1-hour window on price updates, and the governance can freeze the current price value to prevent further updates. In addition to freezing prices, the MakerDAO governance can change the oracle provider with a governance proposal.

Governance

Sky Governance

The Sky Governance process is highlighted below. Users need to seal MKR or SKY tokens into the LockStakeEngine in order to receive voting rights. Users may receive rewards for their sealed tokens. Withdrawing the tokens is currently subject to a fee starting at 5% and increasing up to 15% over time.

The governance contract is DSChief; users can either vote or delegate their vote to other users. A list of Aligned Delegates who vowed to respect the protocol's core values is published on the governance webpage. The current aligned delegates hold a majority of the voting power and extreme influence over the protocol (see security council).

Each proposal comes under the form of a DssSpell, the points to a DssSpellAction contract which holds the logic to be executed upon approval. The Sky Governance uses continuous approval, which means one proposal can be executed at a time, and users need to shift their vote to support a new proposal. The proposal with the most votes at any time is the Hat that can be scheduled and executed. Each Spell may be executed just once and expires after 30 days if it has not been selected to be the Hat.

Proposals can be scheduled for execution with the DSPauseProxy, which enforces a minimal 18-hour delay between approval and execution. Some proposals may exercise non-delayed action to pause some modules of the protocol such as the LitePSM (Peg Stability Module), OSM (Oracle Security Module), liquidations, and debt ceiling. Users can trigger an Emergency and irreversible shutdown of the system by sending 500'000 MKR to the ESM (Emergency Shutdown Module). Funds sent to the contract cannot be recovered, even if no shutdown happens.

Exit Window

The minimum delay between approval and execution of a Sky Governance proposal is 18 hours, recently reduced from 30 hours in an emergency proposal. The Sky Governance has a continuous proposal model, which means voters need to migrate their vote from the current proposal to a new proposal. The proposal with the most votes at any time is accepted and can be executed once its delay has passed.

Emergency measures permissions allow the Sky Governance to pause certain contracts through a proposal without being subject to the mandatory delay. This is the case for all contracts that have a Mom who can pause or stop their child.

In addition to that, an Emergency Shutdown Module exists and can shut down the entire protocol if 500'000 MKR tokens are irreversibly sent to the Emergency Shutdown Contract. Once the process is started, a specific timeline allows token holders and vault users to receive the net value of their assets. If the process is activated, it is irreversible, a fork would need to be created in order to revive the protocol. It is assumed that there are 2 scenarios:

1. A malicious majority is hijacking the Sky Governance. The only option once the system is shut down is to set up an alternative fork in which the malicious users' funds are slashed, and the users who shut down the system see their funds restored.
2. A critical bug was discovered and prevented with a system shutdown. The Sky Governance can refund users who shut down the system by minting new tokens.

Contracts & Permissions

Contracts

The list of contract and deployment addresses is available in both the official documentation and the protocol's chainlog.

 

All Permission owners

 

Permissions