The easiest way to misread Maker is to put every token in one box. A stablecoin holder, a vault borrower and a governance voter have different positions. One holds a token intended to track a dollar. Another owes debt against collateral. The third participates in decisions that can change how the system operates.
Maker’s vault machinery helps explain those distinctions. Sky’s current documentation also makes clear why older names and routes need care. Understanding the original mechanism is useful; assuming an old interface or conversion condition still applies is a separate mistake.
A vault records two sides of a position
The protocol’s Vat documentation describes accounting for collateral and debt. It tracks a vault’s locked collateral, normalized debt and a rate factor that connects that debt to its current amount, including accrued fees. Safety margins and debt ceilings are part of the rules.
Drawing Dai is therefore not the same as selling the collateral. The borrower receives tokens while the vault carries a corresponding obligation. Holding Dai bought elsewhere does not automatically make you the borrower associated with a particular vault.
In a fictional example, Alice locks an asset valued at $3,000 and draws 1,000 Dai. Bob later buys those Dai from her.
| Person | Position after the sale |
|---|---|
| Alice | Holds the collateralized vault position and still owes its debt |
| Bob | Holds the purchased Dai, without taking over Alice’s vault obligation |
Moving the stablecoin transfers the token balance. It does not transfer the debt attached to Alice’s vault.
These are invented names and amounts. They describe the accounting distinction, not an available collateral product or a recommended borrowing position.
A fixed token count can hide a changing ratio
Ignoring fees and treating Dai as $1 for this calculation, Alice’s collateral-to-debt ratio begins at 300%: $3,000 divided by $1,000. If the collateral value falls to $1,800, the ratio becomes 180%. Nothing in that calculation requires the number of collateral tokens to change.
Now suppose, purely for illustration, that the position requires a 150% minimum. At $1,500 of collateral value, the ratio reaches that assumed boundary. A different threshold or accumulated debt would change the boundary. These are not current Sky parameters.
The lesson is how to read the numbers. “I have the same tokens” does not mean “I have the same collateral cushion.” Check which value the system uses, which debt amount is current and which rules apply to that particular position. A market quote and the protocol’s price input may not be identical.
Liquidation turns an accounting problem into a sale
Sky’s liquidation documentation describes transferring insufficiently collateralized vault collateral and debt, then starting an auction intended to obtain Dai and cancel the debt. Its Liquidation 2.0 design uses Dutch auctions with time-dependent pricing.
An instruction to sell is not a guarantee of the proceeds. Buyers, price inputs and auction parameters remain relevant. The documentation itself discusses risks around oracle-derived starting prices and changes to auction behavior.
This matters to both sides of the system. A borrower can lose control of collateral through liquidation. A stablecoin holder depends on the system’s overall ability to handle obligations. The two risks are connected, but their effects on each person’s position differ.
Governance can alter operating rules
The current governance overview describes SKY voting, proposal execution and contracts that enforce a delay before scheduled calls execute. Governance includes executable actions, not just an opinion poll attached to a token logo.
The accounting documentation also identifies dependencies on authorized modules, collateral adapters, price feeds and correct code. Those warnings explain why “runs through smart contracts” is not an assurance that every input or permission is safe.
A useful reader’s question is: what does the proposed action change? A lower fee, a new collateral type and a higher debt ceiling have different consequences. Supporting one change does not mean all future changes are beneficial. This article does not assess a particular vote or audit the deployed contracts.
Dai, USDS, MKR and SKY need separate labels
The USDS documentation describes an Ethereum converter exchanging Dai and USDS one for one in both directions. That is a token conversion. It does not establish that a bank will redeem either token for your dollars, or that every exchange provides the same route.
For governance, the current upgrade information identifies SKY voting in Chief V3, a one-way MKR-to-SKY converter and a legacy Maker voting portal limited to withdrawing MKR from older voting arrangements. It also notes that portal functionality may vary by jurisdiction. These are the documents checked on October 11, 2026; use current official terms before making any decision.
Avoid turning a migration ratio into a statement about economic value. Receiving more units of a differently denominated governance token would not, by itself, prove a gain. This guide does not quote conversion fees, current yields or a guaranteed future route.
Peg tools can bring outside assets into the picture
LitePSM facilitates swaps involving Dai, USDS and external stablecoins such as USDC through pre-minted pools. That helps explain why a vault account alone is not a complete description of the wider stablecoin system.
It also gives a concrete dependency to investigate. A swap into an externally issued token leaves questions about that issuer and its cash-out route. Software can connect those assets without removing the obligations behind them.
An independent 2022 BIS analysis of DeFi lending highlights the economic limitation of widespread overcollateralization: borrowers already need assets, and falling collateral values can reinforce market stress. This is historical, sector-level analysis, not a current Sky safety rating.
Read Maker and Sky by position and mechanism: what you hold, what you owe, who can change the rules and what must work when conditions worsen. That approach remains useful when token names and interfaces change.
