TroveManager: Storage, Trove Struct, Getters

Key takeaway: TroveManager is the protocol's primary storage. Every active Trove is a five-field struct (debt, coll, stake, status, arrayIndex) stored in a mapping(address => Trove). Two more pieces of state make liquidations and redemptions scalable: the TroveOwners[] array (enumerable owner list with O(1) swap-pop removal via arrayIndex) and the running terms L_ETH / L_LUSDDebt (per-stake pending-reward accumulators that distribute redistribution-style liquidations to remaining Troves in O(1) per event). In this section you build the storage, the struct, the BorrowerOperations-callable setters that mutate it, and the view getters — including getEntireDebtAndColl which lazily applies pending rewards. Liquidation and redemption logic is stubbed until later sections.

What You Are Building

TroveManager is going to grow across sections 4, 11, 12, 13, and 15. In this section you build only its skeleton — the data layout and the read/write primitives that BorrowerOperations and the getters need. The functions that actually liquidate or redeem Troves are stubbed; they appear in later sections once the Stability Pool exists to absorb their debt.

By the end of this section, you can deploy TroveManager, have BorrowerOperations open Troves (writing to the storage), and read every per-Trove field. You can also read the lazy "true" debt and collateral via getEntireDebtAndColl — even though the redistribution machinery that creates pending rewards isn't built yet, the read path is wired and ready.