A programmable payment is money that carries its own rules. Conditions, schedules, and purpose bounds are enforced by the ledger at settlement — not by the app that requested them.
Programmability is a property of the payment itself, evaluated at the point of settlement.
A payment can carry conditions that must hold at settlement — a delivery confirmed, a date reached, an oracle attestation present. The ledger evaluates them and commits the transition only if every condition is satisfied.
Conditions are evaluated deterministically against ledger state, so the same instruction against the same state always resolves the same way and can be independently re-verified from the hash chain.
Because the rule is enforced by the rail, programmable money does not require a third party to hold funds in escrow and honor the terms — the ledger is the enforcement point.
A programmed payment is still non-custodial central-bank money with logic attached, not a token wrapper or a stablecoin — the programmability never changes what the value is.
Conditional transfers hold value in a defined state until an on-ledger fact resolves them.
Funds commit to a conditional hold that neither party can unilaterally sweep. Release requires the stated condition; timeout returns value to the payer, both paths enforced by the ledger.
A payment can bind to the transfer of a tokenized asset so both legs settle atomically. The buyer's money releases only as the seller's asset delivers, in one indivisible transition.
External facts enter through signed attestations from authorized oracles — a shipment scanned, a milestone certified — and the payment references the attestation so the trigger is itself auditable.
A transfer can require several signatures before it settles, so disbursements needing joint authorization are enforced by the rail rather than by an off-ledger approval workflow.
Scheduled and recurring payments are anchored to ledger time and survive any single system's uptime.
A payment can be authorized now and set to settle at a defined ledger time, with the authorization held cryptographically so it executes without the payer needing to be online at the moment.
Standing instructions — payroll, pensions, subscriptions — run as ledger-native mandates the payer can inspect and revoke, so a recurring debit is bounded by explicit, auditable authority.
Value can release incrementally over a period rather than in one lump, supporting continuous entitlements or vesting where the schedule itself is enforced by the rail.
Scheduled payments carry defined windows in which the payer or an authority can cancel or amend them, and every amendment is a signed transition, so the schedule's history is fully reconstructable.
Purpose binding lets a disbursing authority constrain where and how value is used without holding the funds itself.
A transfer can be bound to a merchant category, a class of recipients, or a defined use, and the ledger rejects any onward payment that falls outside the scope. The constraint travels with the money.
Subsidies, vouchers, and relief can be issued as purpose-bound value that can only be redeemed for the intended goods, giving policymakers assurance the funds reached their purpose without surveilling every recipient.
Purpose-bound value can carry an expiry after which unspent funds return to the issuing authority automatically, so program budgets do not leak into unbounded float.
The rules attached to purpose-bound money are inspectable by the holder, so a recipient knows exactly what the value can and cannot do before accepting it, and the enforcement is verifiable on the chain.