Programmable money: is it automation or constraint?
Programmability is often described as a straightforward functional improvement. It enables automatic payments, conditional execution and error reduction. In this narrative, programmable money appears to be a natural extension of digital contracts.
The problem lies not in what it promises, but in what it tends to confuse.
In technical terms, programmability refers to the ability to associate logical instructions with payment execution. It is essential to distinguish between two conceptually different levels.
1. Payment automation: an action is performed when an external condition is met.
2. Conditioning of value use: the monetary unit itself incorporates rules about where, when, and how it can be used.
This distinction is often overlooked, but it is central.
Automation concerns how you pay. Conditioning concerns whether you can pay. In the former case, the currency remains neutral with respect to purpose. In the second case, however, it becomes an instrument of embedded policy. The question is not one of intentions, but of architecture: once the constraint is technically possible, its application becomes an administrative choice rather than a structural limitation.
Abstract examples help to clarify this. An automatic subscription payment is an example of automation. A sum that can only be spent on certain categories of goods is a form of conditioning. Both solutions are technically feasible. The difference is that the latter changes the nature of money, transforming it from a general means of payment into a means of payment for a specific purpose.
This is where the concept of 'policy drift' comes in. Rules that are introduced for limited purposes tend to expand over time. This is not due to abuse, but rather due to the internal consistency of the system. If a function is useful in one context, it makes sense to extend its use to other contexts. Ultimately, what starts as an exception can become the operational norm.
In the context of CBDCs, programmability is not an accessory. It is a potential property of the infrastructure. Even if it is not initially activated, its presence alters the balance between rules and discretion. The phrase 'it depends on how you use it' loses its analytical power; what matters is what the system enables you to do, rather than what it promises not to do.
Some digital monetary systems adopt the opposite logic: the rules are public and rigid, and cannot be changed on a case-by-case basis.
As a distributed cryptoasset, Bitcoin does not incorporate intended uses. It does not distinguish between purposes, identities or contexts. It is not programmable in the sense of conditioning. However, it is verifiable in terms of compliance with rules.
The difference is not between good or bad technology.
Rather, it is between automation that facilitates and constraints that guide.
#automation #vs #comditioning #cbdc #bitcoin #verify #digital #monetary





















