Interactive systems demo · 01
CashFlow Engine
An interactive crypto kiosk controller — from customer action to physical cash outcome.
I built the original controller around a real bill recycler, serial protocol, remote callbacks, persistent cash inventory, and a finite-state machine. This reconstruction lets you explore that engineering without exposing proprietary names, endpoints, infrastructure, or transaction data.
Three good places to start
Try the system from three different angles
Buy → Happy path
Watch a bill approach the validator, pause in escrow for the host decision, stack, update inventory, and complete the generalized asset purchase.
Sell → Happy path
See the opposite direction: host confirmation, payout planning, physical cash movement out of the recycler, customer pickup, and inventory reconciliation.
Inject a failure
Choose a timeout, jam, bad frame, open box, or communication loss and watch the controller switch from normal workflow to containment and recovery.
Customer view
What the person at the kiosk sees
Insert a $20 bill to begin.
Controller internals
Standby
Internal dialog
Events, callbacks & protocol meaning
- Transaction
- Idle
- Last response
- Standby
- Host decision
- —
- Recovery
- Not required
Explore the documented state & response catalog
I condensed the original controller's larger event surface into readable families here. Choose a state to see why it mattered operationally.
This reconstruction preserves the controller's documented sequencing and failure reasoning while generalizing organization-specific names, payloads, endpoints, and device identifiers. Timing is intentionally compressed for explanation rather than presented as a production benchmark. The digital-asset network step is a generalized host-side wrapper around the documented cash-control subsystem.
Why this demo exists
A static diagram cannot show the moment when software intent and physical reality diverge.
That was the interesting part of this system. Sending a command was never enough. The controller had to wait for the device, understand what physically happened, preserve partial progress, update records, and choose a recovery path that did not accidentally move more money.
The simulator makes those boundaries visible. On desktop, it is organized as a control-room view so the customer experience, controller state, physical inventory, and internal protocol trace can be followed together. Smaller screens progressively stack those views instead of forcing the desktop density into a narrow layout.
The digital-asset step is intentionally generalized as the host-side transaction layer. The cash-control sequencing and state behavior are reconstructed from the preserved engineering documentation and portfolio evidence.