Requirement for **Release 2**. ## The problem `PaymentTopUpSource` assumes the product already holds the money. A user who hits `InsufficientBalance` has reached a dead end: nothing in the protocol moves value from the outside world into their CASH balance, so the product can only report the failure and stop. In the other direction there is no path at all — value cannot leave. There is also no declared contract for who can move that value, so every provider integration lands as bespoke host code rather than as a product declaring what it serves. ## What has to be true for Release 2 **Moving value** - [ ] A user can move value in, from the outside world to their CASH balance - [ ] A user can move value out - [ ] A product declares a funding intent and watches it through to a terminal state - [ ] A funding session survives a host restart - [ ] The user is never told value arrived before it actually did **Providers** - [ ] A product declares the funding modality it serves in its manifest, and serves intents addressed to it - [ ] The host builds its funding source list from dotNS records alone, before any provider code runs - [ ] Routes are declared statically in the manifest, so the rail list needs no provider code - [ ] Rails are expressible across cash, bank, card, friend, exchange and foreign-chain **Everywhere** - [ ] Works on every host that claims support ## Delivery is staged The requirement is the whole surface — both directions and the provider system. It is delivered in stages, and the stages live in the feature issues, not here. A stage landing narrower than this requirement is expected; the requirement is not amended to match it.