№ 19 · Flow

The machine room.

every call · every object

How a loan actually moves.

This is the whole lending process — not a marketing diagram, but the real contract surface of the Sui silo, function by function. Pick a scenario, step through it, and watch which objects touch which: the shared Pool<T>, your owned Position, the AI-tuned Curve, the oracle guards, the Sentinel's single-use attestations, and the hot-potato receipts that make atomicity a type-system guarantee.

Every signature shown is lifted from the audited-candidate source (76/76 tests green). The Ethereum launch silo re-implements the same flows in Solidity — same invariants, different machine.

№ 19-A

Step through it.

8 scenarios
step 1 / 4

№ 19-B

Why the object model matters.

the guarantees
  • The pool is shared; your position is yours. Pool<T> is a shared object anyone can transact with, but a Position is owned — only your key (or your PTB) can present it. There is no global ledger of user balances to corrupt; there are only objects you hold.
  • Hot potatoes make atomicity a compiler guarantee. FlashReceipt<T> has no drop and no store: the transaction literally cannot end until flash_repay consumes it. Under-repayment is not detected — it is unrepresentable.
  • Attestations are single-use by type. A SentinelAttestation is consumed on use, is bound to one target object, and expires. Replay is not filtered; it is impossible.
  • Every arrow emits an event. Each state change fires a typed event from events.move — the raw feed behind the T+0 reporting promise.
  • Same flows, every silo. These are the Sui-silo mechanics; the Ethereum launch silo re-implements the identical invariants in Solidity. The philosophy does not fork.
№ 19-C

Read next.

deeper