[andrewla]

I'm going to stick with nearly impossible. Yes, it is theoretically possible to have a fixed number of built-in contract types that follow a certain schema, and to make a UX corresponding to each one. But in the full generality -- you get one of these crowd-funding contracts, and the client has to figure out what kind of counterparty signing has to happen in order to spend these damn things. Without prior knowledge of the structure, I'm guessing that this verges on intractable.

Of course, with a finite number of transaction types, this is easy, right? Well, not even then. Because you don't redeem these things when you _receive_ them. You redeem them when you _spend_ them. There's no easy solution here; most likely the clients will have to do a one-time sweep of receptions that it knows how to complete to an unencumbered transaction input, so that they can be spent without having to gather a bunch of documents. But at the very minimum, a very challenging experience compared to cash, or even the "standard" transaction inputs.