Vault value-conservation invariant is a no-op for the entire lending flow (medium). VaultInvariant.cpp:1049-1054 — ttLOAN_SET / ttLOAN_MANAGE / ttLOAN_PAY are literally // TBD → return true. Loan transactions move real vault assets and mutate sfAssetsAvailable/sfAssetsTotal, yet are exempted from ValidVault. The only "funds conserved" / "pseudo balance agrees" checks on that path are #if !NDEBUG asserts (no-ops in Release). And unlike LoanBrokerInvariant (which cross-checks its cover pool against the broker pseudo-account's real balance), no production invariant ever ties the vault's sfAssetsAvailable to the vault pseudo-account's held balance. Not a live exploit today, but the last line of defense is switched off for the most complex value flow in the system — any present-or-future loan-accounting desync commits to hashed ledger state undetected. Still // TBD on develop.
Vault value-conservation invariant is a no-op for the entire lending flow (medium). VaultInvariant.cpp:1049-1054 — ttLOAN_SET / ttLOAN_MANAGE / ttLOAN_PAY are literally // TBD → return true. Loan transactions move real vault assets and mutate sfAssetsAvailable/sfAssetsTotal, yet are exempted from ValidVault. The only "funds conserved" / "pseudo balance agrees" checks on that path are #if !NDEBUG asserts (no-ops in Release). And unlike LoanBrokerInvariant (which cross-checks its cover pool against the broker pseudo-account's real balance), no production invariant ever ties the vault's sfAssetsAvailable to the vault pseudo-account's held balance. Not a live exploit today, but the last line of defense is switched off for the most complex value flow in the system — any present-or-future loan-accounting desync commits to hashed ledger state undetected. Still // TBD on develop.