There is a kind of money that does not behave like ordinary money. I first experienced it as a student when I received a scholarship. It came with conditions. I had to maintain a certain grade average, complete volunteer hours, and stay enrolled in a specific program. The funds arrived every semester, but they were not unconditional. If I failed to meet the requirements, the payments stopped. If I used the money outside the approved categories, I risked losing eligibility entirely. That scholarship was not just financial support. It was money programmed to follow rules.
Reading through Sign’s programmable CBDC conditional payment mechanics this week brought that memory back. The design is solving a problem governments have always faced: how to ensure distributed funds are used for the purpose they were distributed for. The technical implementation is impressive. But the same capability that solves that problem also enables something else that the whitepaper does not address.
Sign’s CBDC infrastructure supports token-based conditional transfers through the Fabric Token SDK. It uses the UTXO model, where unspent transaction outputs track token movements through a directed acyclic graph. Each transaction consumes previous outputs and creates new ones. This model is efficient for conditional logic because conditions can be encoded directly into the output creation rules.
The conditions described in the whitepaper are extensive. Time-locks release funds after a specified period, useful for pensions or vesting schedules. Multi-signature requirements ensure that high-value transfers require approval from multiple authorized parties. Compliance attestations link transfers to verified identity attributes, so subsidies reach only verified recipients. Usage restrictions limit how tokens can be spent, such as housing benefits usable only at registered providers. Geographic constraints restrict spending to specific regions.
Each of these maps to legitimate policy objectives governments have pursued for decades. The innovation is not the policy itself but the enforcement. Instead of relying on case workers or administrative checks, the enforcement is cryptographic. A usage restriction encoded in the token is not a guideline. It is a mathematical constraint. The money simply cannot move in a way that violates the condition. For fraud prevention and targeting efficiency, this is a major improvement. A conditional token eliminates entire categories of distribution failure that have historically been common and costly.
Yet what troubles me is that the conditions are parameters, and parameters have no described constraints. The whitepaper lists examples but does not describe them as the complete set. Nor does it describe any mechanism for limiting which conditions a government can attach to which payments. That means the same infrastructure that enforces a housing benefit restriction could also enforce a benefit usable only at government-approved vendors. Or a payment that expires if the recipient fails a periodic check-in. Or a transfer that becomes void if the recipient moves to a restricted zone. None of these require modification to the architecture. They are simply different uses of the same conditional logic.
I am not claiming Sign intends these uses. I am saying the architecture enables them, and the whitepaper makes no distinction between legitimate and potentially coercive applications. That gap matters.
There is a historical pattern worth naming. Financial infrastructure that enables conditional spending has existed before. Restricted benefit cards, earmarked grants, conditional cash transfers. In every case, conditions expanded over time as institutions discovered new policy objectives they wanted to enforce. The difference with programmable CBDC conditional payments is scale and precision. Traditional systems required significant administrative infrastructure, which limited complexity. Cryptographic enforcement requires no additional overhead. The cost of adding a new condition approaches zero.
For sovereign infrastructure that could eventually handle pensions, welfare, or basic income, that combination is powerful and dangerous. Zero enforcement cost for conditions of arbitrary complexity, attached to payments citizens depend on, describes something that needs accountability frameworks. The whitepaper places programmable payments alongside fraud prevention and efficiency gains. It does not describe governance constraints on the scope of conditions. That absence feels significant.
So I find myself torn. On one hand, this may be the most efficient and fraud-resistant benefit distribution infrastructure governments have ever had. On the other, it may be the technical foundation for a form of social control never before achievable at national scale. The truth is that it is both. The architecture is neutral. Its uses will be determined by policy choices. But neutrality in design does not absolve responsibility. When money itself learns to obey, the question is not only what rules it can follow, but who decides the rules, and how those decisions are constrained.
That is the conversation missing from the whitepaper. And it is the conversation we need to have now, before programmable conditional payments move from theory into everyday life.