Maybe it’s time revise Friedman and his intellectual heirs — something along the lines of “…but *asset* inflation is always and everywhere a commercial banking phenomenon.”

I think in this sense Kiyotaki & Wright (et al.) are on the right track; money is just the discrete/divisible technology that best satisfies to requirements for sustaining *liquidity* within an economy that is dominated by rival goods and services. Rivalry of real factors (among other things) entails scarcity, which in turn necessitates the use of symmetrically rival liquidity mechanisms to facilitate the maintenance of nonzero supplies as well as a (more) efficient allocation of factors across potential uses/users.

Re: the distinction between money and debt, I believe the relevant points of symmetry would be “portable” network addresses (here meaning the kind that are global-scope unique/useful, and which do not have any inherent or necessary association with any particular network-operating institution), vs. “non-portable” network addresses, which may have a variable scope of usability (ranging from “loose construction” global scope to “strict construction” local-only scope), the availability and usability of which which is always, by definition, contingent on the intermediacy of a specific third-party intermediary — in this case a network operator. Under some sets of conditions (e.g., very, very accommodating network intermediaries) both kinds of addresses may be equally useful in the wider economy, for engaging in the exact same range/mix of exchange transactions — although use of the non-portable addressing would always guarantee a recurring revenue stream to the specific (literally) “originating” network operator. In many cases however, users might also encounter additional technical limitations in how the originated resources might be used, as dictated by the originator (with the extreme case looking less like bank debt and more like merchant revolving credit).

The model described above provides for the full range of recurring, systemic monetary problems. Inflation and deflation might have a number of different sources (surplus/deficit of intermediaries, profligacy/excess conservatism of intermediaries, failure of inter-provider coordinator or super-provider monetary authority to maintain industry-level entry/exit/population levels, and/or the right quantities/mix of liquidity technologies in circulation), and stagnation might arise as a result of loss of the consistency/predictability (or confidence therein) that the various liquidity technologies themselves will continue to function as designed over time and distance…

As in instances of monetary liquidity systems, causes behind particular moments of systemic instabilities are always subject to debate — but making valid, plausible inferences, either for real-time management purposes or post-facto forensic analysis, inevitably requires a high degree of direct, hands-on experience and “know-how” about the what level of statmux is sustainable given observed service flows/inter-temporal demand patterns.

Consider that in order to function as a reliable participating node in this system of “packetized liquidity” (i.e., network of inbound and outbound debt flows), every participant needs to possess some underlying fungible capital stock. For the larger, more central nodes that can both originate, terminate, and propagate/”transit” these flows, this is called “capital reserves,” while for the smaller, more distal nodes — which can generally only terminate such flows it’s called “collateral.” At the banking-node level, the canonical goal/challenge is to maximize over time the overall revenues accruing from the largest/best mix of (inbound + outbound + transited) liquidity flows that can be accommodated given the existing level of capital reserves. Part of that work involves flows between bank-nodes and end-user-nodes, but as interconnectedness and information processing technology improves, a growing share of the activities will occur between the bank-nodes themselves; in one domain such activities are called “traffic engineering,” while in the other it’s “proprietary trading” (or perhaps more generically “financial engineering”…?).

The recent, arguably unprecedented problem arises when improvements in information processing technology begin to blur the distinction between the flows and the underlying reserves to such a degree that (a) the bank-nodes themselves have increasing difficulty distinguishing between the two classes, and as a result (b) even the domain experts — who are the only participants with any solid factual knowledge of the state of any part of the system — no longer know how to calculate or maintain the safe/sustainable flows-to-reserves ratio.

The result first became visible in the other domain, in mid-2002…

http://www.eyeconomics.com/eyecononomics.com/Presentations/Pages/Bankers_for_BGP_v1.2.html

http://www.eyeconomics.com/eyecononomics.com/Presentations/Pages/The_Internet_as_a_Liquidity_Mechanism.html

The other point i should have made is that the same symptoms, inflation, deflation, can have a lot of different causes in monetary statistics, so if the M2 money supply is growing rapidly, and it’s not immediately obvious if that’s a growth in debt or money, or even both, well that could be a problem.

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_11-4/114_letters.html

Nice to find someone else working in the same general space!

http://preview.tinyurl.com/IPliquidity
(presented at the IAB meeting at IETF 74)

http://preview.tinyurl.com/LMdefined
(comparison of monetary vs. protocol-based liquidity mechanisms)

TV

The other thing I liked about your post was the approach of looking for a bug. One thing I’ve always found dissatisfying about economic theory is that there is so little way to test or really apply it. I think the finding a bug attitude is a partial solution to that.

Thanks again for the nice post.