Skip to main content
← Oracle Tier Evidence

sUSDS (sUSDS / USDS)

Oracle deep-dive for 0xa3931d71877c0e7a3148cb7eb4463524fec27fbd — Sky Savings USDS.

  • Source: Upgradeable Proxy (ERC1967)
  • Pair: sUSDS / USDS
  • Score: 0.2
  • Tier: Very High Risk
  • Slug: proxy_eth_susds_usds

Contract Architecture​

sUSDS is a savings wrapper over USDS (formerly DAI Savings Rate). The contract uses the ERC1967 proxy pattern (UUPS) — the token address is a proxy whose implementation can be upgraded by authorized actors.

The pair is sUSDS / USDS (not sUSDS / USD) because the contract's exchange rate function converts sUSDS shares to USDS amounts. The price path to USD requires an additional USDS/USD feed.

Implementation: 0x4e7991e5C547ce825BdEb665EE14a3274f9F61e0 (verified on Etherscan).

Risk Dimensions​

DimensionObservationImpact
UpgradeabilityERC1967 proxy (UUPS pattern)Logic can change without changing token address
Upgrade authorityauth modifier with wards[msg.sender] == 1, _authorizeUpgrade() gated by authPrivileged actor can upgrade implementation
Admin surfacerely/deny/file functions behind authParameter changes affect behavior
External dependenciesSky/Maker-style modules (joins, vat patterns)Peg + accrual mechanics are system-dependent
Oracle suitabilityExchange rate derived from internal accountingNo independent market price discovery

Primary Evidence​

auth modifier — gates all privileged operations:

modifier auth {
    require(wards[msg.sender] == 1, "not-authorized");
    _;
}

_authorizeUpgrade — implementation swaps gated by same auth:

function _authorizeUpgrade(address newImplementation) internal override auth {}

Any authorized ward can point the proxy to a completely new implementation. The exchange rate, accrual logic, and withdrawal behavior can all change.

rely/deny/file — governance parameter surface:

function rely(address usr) external auth { wards[usr] = 1; }
function deny(address usr) external auth { wards[usr] = 0; }
function file(bytes32 what, uint256 data) external auth { ... }

The file pattern (inherited from MakerDAO) allows arbitrary parameter changes by authorized actors.

Why Very High Risk (0.2)​

The upgrade path is the dominant risk. Unlike an immutable ERC-4626 vault where the risk is accounting manipulation, an upgradeable proxy means the entire contract logic can be replaced. The exchange rate today tells you nothing about what the exchange rate function will compute tomorrow if the implementation is swapped.

Combined with the rely/deny ward system (as opposed to a timelock or DAO vote), the upgrade authority is concentrated and can act without delay.

Mitigations That Could Raise the Score​

  • Verified upgrade admin (multisig/DAO) with timelocked upgrades
  • Circuit breakers on implementation changes
  • Dual-oracle cross-checks against USDS/DAI market prices
  • On-chain monitoring of Upgraded(address) events with alerting