USDS is “upgradeable money” by design, and that is the point you should model first

USDS is the Sky ecosystem’s upgraded stablecoin, launched after MakerDAO rebranded to Sky in 2024, as described in the ecosystem whitepaper.

Mechanically, it is very close to DAI. Sky’s own whitepaper describes USDS as a decentralized, collateral-backed stablecoin that is technically an IOU token representing a collateralized balance inside the protocol’s core accounting (“vat”) just like DAI.

The meaningful difference is not branding. It is contract mutability. Sky’s developer docs state that the USDS token is built with upgradeability via the UUPS pattern and ERC-1967 proxy storage, as outlined in the token design docs.

Sky’s whitepaper makes the intent explicit. It says USDS may eventually be upgraded to include a freeze function, that the freeze function is not yet implemented, and that the deployment is proxy-upgradeable (ERC1967Proxy) so such functionality could be added via decentralized governance vote.

From an Operator Discretion Skeptic angle, this is the core trade-off. USDS optimizes for iteration speed and “policy surface area” at global scale. That is compatible with RWA expansion. It also creates a stablecoin whose long-run risk profile depends less on code immutability and more on governance process integrity.

Supply: elastic, collateral-driven, and intentionally coupled to DAI

USDS does not have a fixed supply schedule. It expands and contracts with user demand and protocol balance sheet mechanics, since it represents protocol liabilities against posted collateral in vaults.

The important “tokenomics” constraint is the coupling to DAI. Sky’s docs describe a DAI↔USDS converter route where USDS is linked to the same issuance source as DAI, and holders can convert between the two at any time with no liquidity restrictions.

On the contract side, Sky’s USDS token page is blunt about the conversion invariants. The converter performs 1:1 conversions between DAI and USDS. It charges no fees. More interestingly, the docs claim that fees cannot be enabled on this route in the future.

The whitepaper frames the same idea in economic terms. It says USDS launched alongside a converter that allows “free and infinitely liquid conversions” between DAI and USDS.

This design matters because it splits “stablecoin product surface” from “core issuance ledger.” If you are modeling USDS adoption, you are really modeling the incentive and UX layer that drives users to hold USDS instead of legacy DAI, while the underlying issuance engine stays continuous. If you want a quick baseline on terms and moving parts, start with our tokenomics FAQ.

There is no pre-mine or allocation logic to analyze the way you would for a typical volatile token. Supply is minted into existence through protocol pathways, then retired when liabilities are repaid or tokens are burned via redemption-style flows. Your key variable is not emissions. It is the net balance of issuance demand (vault borrowing and other entry points) versus exit demand (repayment, conversion, and liquidity routes). That stands in contrast to Litecoin’s supply schedule, where emissions are pre-programmed.

Utility and fiscal flows: where USDS demand comes from, and where “fees” actually show up

USDS utility inside Sky is less about “payments stablecoin” and more about being the entry ticket to a set of protocol-native modules: conversion, fixed-price liquidity, savings yield, and rewards programs. The economic question is which module is marginal at the cycle you are in.

At the base layer, the protocol charges stability fees on vault debt. Sky’s whitepaper describes the stability fee as an annualized fee paid when vault debt is paid down or closed, and it states stability fees must be paid in DAI.

That detail is easy to skip, and it creates a subtle tokenomics consequence. Even in a USDS-forward UX, parts of the system’s “tax base” are still DAI-denominated at the core. USDS then competes on top of that via conversion guarantees and incentive modules.

The second major locus of “fees” is not vaulting. It is peg liquidity infrastructure. Sky’s LitePSM guide describes LitePSM as enabling swaps between USDS (or DAI) and USDC at fixed exchange ratios and fees, with the explicit goal of stabilizing the stablecoins around their peg, as detailed in the LitePSM user guide.

USDS↔USDC routing is handled through a wrapper that converts USDS to DAI internally so the system can share USDC liquidity and avoid fragmentation across “two stablecoins that are meant to be equivalent.”

Here is the discretion lever: LitePSM fees are governance-set. The docs state tin is assessed on sellGem transactions and tout on buyGem transactions, and both are set by Sky Ecosystem governance.

And the “break glass” lever is even more direct. The same guide states governance can set tin or tout to type(uint256).max, which halts the corresponding swap direction for all users.

That is not theoretical decentralization nuance. It is a concrete, measurable liquidity risk factor. Your stablecoin can be collateralized and still become functionally illiquid at the most important “hard peg rail” if governance chooses to halt, or if governance is forced to halt due to external constraints.

Savings and incentives: sUSDS makes the Savings Rate composable, and “no-fee forever” is the real promise

USDS demand is structurally supported by protocol-native yield. Sky’s sUSDS documentation says sUSDS is a tokenized implementation of the Sky Savings Rate for USDS, implemented as an ERC-4626 vault, per the sUSDS documentation.

The same page emphasizes two design choices that matter to integrators and risk analysts:

That “fees cannot be enabled” line shows up in multiple places across Sky’s token routes. It is an unusually strong commitment in a system that otherwise embraces upgradeability and governance control. It looks like an attempt to draw a hard boundary between (a) governance-controlled monetary policy parameters like rates and (b) rent extraction on user-facing plumbing.

Rate-setting is still discretionary. Sky’s legal risk documentation describes the Sky Savings Rate (SSR) as variable, governance-determined, and explicitly warns the rate may drop significantly, go to zero, or even become negative depending on governance decisions and market conditions, as noted in the legal risk notes.

There is also a second incentive vector: token rewards programs that pay governance tokens for USDS participation. Sky’s Sky.money features page describes “Sky Token Rewards” as a module where supplying USDS yields token rewards over time in the form of Sky Star tokens, and frames it as non-custodial with no minimum and withdrawal at any time.

Governance documentation shows these rewards are actively managed. For example, an executive proposal template describes “USDS → SKY Farm Normalization,” including actions to adjust how SKY token rewards are distributed to USDS holders so that the effective yield matches the Sky Savings Rate (SSR), as in the December 11, 2025 executive vote template.

Tokenomics implication: USDS demand is being “pulled” by endogenous yield and incentives. That can be productive. It can also make USDS supply more reflexive. If incentives are dialed up, USDS demand rises and supply routes respond. If incentives are dialed down, the system needs the rest of its value proposition to hold. For a reference point on how another yield-bearing wrapper frames incentives, compare with our Wrapped eETH review.

Governance and control surface: the system is decentralized, but it is not discretion-free

Sky’s protocol governance architecture is conventional for Maker lineage and still worth calling out because USDS explicitly leans into upgradability.

Sky’s governance overview states the governance module has three core components: Chief, Pause, and Spell.

The overview also describes the Pause contract as a delegatecall proxy with an enforced delay, used to schedule function calls that can only be executed after the waiting period elapses.

The Pause page reiterates the same: ds-pause enforces a delay and there is “no way to bypass the delay” under its critical assumptions.

This delay is a genuine constraint on operator discretion. It is also not a full answer, because discretion still exists within the space of “what can be queued,” and because governance capture can still schedule destructive changes with enough time for markets to react, not necessarily enough time for all users to exit cleanly. For a contrast case where governance is itself a primary value driver, see our Uniswap tokenomics review.

On the contract-level authorization side, privileged roles are explicit. In the Pot contract documentation (core to the Dai Savings Rate), “wards” are defined as addresses allowed to call protected administrative functions, and the docs state parameters like dsr and vow can be changed by an authorized address, meaning governance.

The “operator discretion” footprint is not limited to on-chain contracts. Sky’s security measures overview states that front-end web applications implement IP screening, geo-blocking, VPN blocking, and sanctions compliance features that restrict access in certain regions.

That is a realistic posture for a project that wants to scale in today’s regulatory environment. It is also an availability risk for users who rely on the canonical UI. If you are integrating USDS, the right mental model is “protocol access is on-chain, product access is mediated.”

Finally, multi-chain expansions add their own governance hooks. Sky’s SkyLink Ethereum-Base bridge guide states that customizations to the bridge allow Sky governance to manage token support and add new features when needed.

Risk analysis: USDS tokenomics is mostly governance risk wearing a stablecoin badge

USDS is easy to mistake for “DAI with a new ticker.” The mechanism-level reality is sharper. USDS is DAI-like collateralization with a deliberately larger discretion budget, expressed through upgradeable token contracts, governance-controlled liquidity rails, and governance-managed incentive programs.

Dominant risk: discretionary upgrade path (freeze and beyond)

Sky’s own materials lay out the path. USDS is explicitly engineered for upgradeability. The USDS token docs state UUPS upgradeability with ERC-1967 proxy storage.

The whitepaper then ties that upgradeability to a specific class of future change: a potential freeze function. It says the freeze function is not yet implemented, but could be added later via a governance vote because the token is proxy upgradeable.

That is not automatically “bad.” For a stablecoin with growing RWA exposure, a freeze capability can be framed as theft mitigation, error recovery, or compliance compatibility. CoinGecko even highlights “Freezing Functionality” as a differentiator on its USDS overview page.

The problem is not the existence of a tool. The problem is the shape of the authority graph around it, and the second-order effects once such a capability exists.

Once USDS becomes plausibly freeze-capable, every large integrator, exchange, custodian, and bridge will model a new tail scenario: a governance-approved (or governance-compelled) action that changes the token’s censorship resistance properties. Some counterparties will treat that as a feature. Others will treat it as a regime risk and demand a discount, especially for long-dated strategies where governance composition can change.

It also changes “bank run math.” With an immutable stablecoin, the dominant run dynamic is peg confidence versus collateral quality and liquidity. With an upgradeable stablecoin, there is a second run dynamic: governance credibility. A contentious governance moment can create pre-emptive exits, even if collateral is fine, because users are front-running a policy change rather than a balance sheet impairment.

The Pause delay helps, but it does not eliminate the risk. The Pause contract enforces a delay before scheduled actions can execute.

That means you can sometimes see governance intent before it lands. It does not guarantee you can exit cheaply. In stress, liquidity is path-dependent. And if the same governance that can upgrade the token can also adjust liquidity rails, the “exit window” is not a single control.

If you want a clean USDS model, treat upgradeability as a first-class parameter. You do not need to predict whether a freeze function will be added. You need to treat it as a live branch in the design tree, and discount for that uncertainty unless you have strong reasons not to.

Top 3 risks

  1. Governance-led token mutability (dominant). Trigger: a governance proposal to upgrade the USDS proxy implementation, especially one that adds or activates freeze-like behavior. Mechanism: USDS is designed for upgradeability (UUPS + ERC-1967 proxy), and the whitepaper explicitly contemplates a future freeze upgrade via governance vote. Who bears it: USDS holders (censorship and settlement risk), DeFi integrators (listing and collateral risk), and cross-chain wrappers (bridge policy risk). Measurable indicators: queued and executed governance spells affecting USDS contracts, implementation address changes, and any formalization of “freeze policy” language in official docs or governance forums.

  2. Peg liquidity rail discretion (PSM halting and fee shocks). Trigger: governance response to depeg pressure, regulatory stress on USDC liquidity, or operational risk in the LitePSM system. Mechanism: LitePSM fees (tin/tout) are governance-set, and governance can halt swap directions by setting fee parameters to type(uint256).max. Who bears it: users who rely on USDS↔USDC conversion as a hard liquidity backstop, and protocols that assume stable, callable exit liquidity in stress. Measurable indicators: sudden changes in tin/tout, swap failure rates, and persistent widening of USDS price bands versus $1 across major venues.

  3. Cross-chain governance and bridge adaptation risk. Trigger: bridge upgrades, token support changes, or a bridge incident that forces governance intervention. Mechanism: Sky’s bridge guide states that governance can manage token support and add new features to the Ethereum-Base bridge via customizations to the OP Stack bridge code. Who bears it: holders of bridged USDS and sUSDS, and integrators on L2s that treat bridged USDS as fungible with L1 USDS. Measurable indicators: bridge contract upgrades, paused deposits/withdrawals, abnormal escrow balances, and repeated governance actions touching bridge allowlists or governance relay components.

If you are doing tokenomics consulting work around USDS integrations, the practical deliverable is a control-surface map, not a glossy “stablecoin primer.” A tokenomics advisor should be able to show which parameters are immutable (fee-free converter and sUSDS route constraints) versus governance-controlled (rates, PSM fees, and upgrade paths), and how those choices change worst-case outcomes.

USDS can work well as a scalable, yield-bearing stablecoin inside a complex on-chain credit stack. The price is that its most important risks are human coordination risks. That is exactly where stablecoin models tend to break under real stress. We publish ongoing stablecoin research reports that track these control-surface variables over time.



This article is part of our Tokenomics Deep Dive series.