Programmable Money

A bank account is passive. It holds a number and waits for a human to move it. Stablecoins on a smart-account kernel are not passive: money can carry its own rules and act on them, on-chain, within limits the owner set in advance. That is what "programmable money" means in AURA, and it is a direct extension of the architecture already described, not a new system bolted on.

The standing rule, restated for automation

The human arms a rule once, under strong authentication. Deterministic code and the on-chain policy enforce it thereafter. The AI may draft a rule; it never arms one, and it never holds a key.

From a one-off intent to a standing intent

The AI architecture already reduces every user action to a structured intent that deterministic code validates before anything moves. A one-off payment is a single intent confirmed and signed in the moment. An automation is the same idea persisted: an intent with a trigger and a pre-authorised scope, so it can fire later without a fresh prompt.

	One-off intent	Standing intent (automation)
Confirmed	Per payment, in the moment	Once, when the rule is armed
Triggered by	The user, now	A schedule, a threshold, or an event
Executed by	Passkey signature	A scoped session key, under policy
Bounded by	The auth ladder at send time	The same ladder, checked on every fire
Stopped by	Not sending	Revoking the rule; the cooling-off window

type StandingIntent = {
  kind: 'autopay' | 'stream' | 'allocation' | 'allowance' | 'conditional';
  trigger:
    | { on: 'schedule'; rrule: string }        // e.g. rent on the 1st
    | { on: 'received'; split: Allocation[] }   // salary hits, split it
    | { on: 'threshold'; balanceAbove: string } // sweep the surplus
  payeeId?: string;   // MUST resolve to a saved, screened payee, never a raw address
  currency: 'USD' | 'EUR' | 'GBP';
  perFireCap: string; // enforced on-chain, not in the client
  dailyCap: string;
  expiresAt: number;
};

The injection defence from the AI pipeline carries over unchanged: a standing intent can only ever pay a payee the user has already saved and screened. A rule can never introduce a new destination.

The execution model: who may act without a prompt

Automation appears to break the rule that the human confirms every payment. It does not. The confirmation moves in time rather than disappearing. Arming a rule is a policy change to the account, and by invariant 4 every policy change, trusting a payee, installing a validator, setting a limit, is a Tier 4 operation requiring the account's strongest authentication. Once armed, each execution runs on a session key whose scope was fixed on-chain at arming time.

flowchart LR
    A["Human arms rule<br/>(Tier 4 auth)"] --> S["Scoped session key<br/>minted on-chain"]
    T["Trigger fires<br/>schedule · threshold · receipt"] --> V{"AuraSecurityManager<br/>hook checks the ladder"}
    S --> V
    V -->|within scope| EX["Execute · reconcile · notify"]
    V -->|out of bounds| Q["Refuse or queue<br/>for human review"]

A session key here is exactly the instrument defined for Tier 0: bound on-chain to a per-transaction cap, a cumulative daily cap, trusted payees only, allowlisted tokens only, a short expiry, and instant revocation. An automation is therefore incapable of paying an address the user never verified, or of spending past a ceiling the user set, because those bounds live in the kernel, not in the code that schedules the rule.

What you can build

Each of these is the same primitive, a scoped, triggered intent, wearing a different trigger.

Capability	Trigger	Executes as	Status
Autopay / standing orders	Schedule (rent, subscriptions, payroll)	Session key, capped, to a trusted payee	Designed
Streaming income	Continuous, per unit time	Inbound stream rendered as "cleared as you earn"	Planned
Auto-allocation	On receipt (split salary; round-ups; sweep surplus)	Internal transfers between the user's own balances	Designed
Allowances / delegated spend	On demand, by a delegate	A separate scoped key with its own caps and expiry	Designed
Conditional payments	Threshold or event	Session key, checked against live chain state	Planned

Allowances are worth calling out: a delegated budget for a family member, a team, or a contractor is not a shared password. It is a distinct session key with its own per-payment cap, daily cap, trusted-payee set, and expiry, revocable independently and instantly. The delegate can spend within the envelope and observe nothing outside it.

The regulated frontier: money that earns and borrows

The consumer vision of programmable money also includes idle balances that earn, and holdings you can borrow against without selling. These are architecturally natural as further ERC-7579 modules, and deliberately gated on more than code.

These are Planned, and partner- and licence-dependent

• Yield on idle balance. Routing unused balance to a yield source resembles deposit taking and can implicate securities and e-money rules. It arrives through licensed partners, with terms and risks disclosed in plain language, never presented as a guaranteed rate.
• Borrow against holdings. A collateralised credit line is a lending product with its own licensing surface. Designed as a module; not offered until the regulatory path is clear.
• Tokenised real-world assets. Fractional exposure to property, funds, or equities expands the asset set beyond the four vetted stablecoins. That allowlist is itself a security control, so loosening it is a deliberate, audited decision, not a default.

The honest position: the programmable-payments layer is native and near. The programmable-investing layer is real, designed as modules, and correctly slowed by regulation. The whitepaper marks them apart so the roadmap never implies a capability that counsel has not cleared. See Roadmap.

Guardrails: automation that cannot run away

The failure that matters is an automation that quietly drains an account or pays a scammer on a schedule. Every control that protects a manual payment protects an automated one, because they share the same kernel.

1. A rule is not a new trust. Arming an automation cannot add a payee or raise a limit. Both remain Tier 4, done by the human, never by the rule and never by the AI.
2. Every fire passes the ladder. The AuraSecurityManager hook runs on the automated execution exactly as on a manual one. A rule that drifts out of scope is refused or queued, not forced through.
3. First-payment cooling-off still applies. A first large payment to a new payee waits in the on-chain cooling-off window even when a rule initiated it, so a mistaken or coerced rule can be cancelled after the fact.
4. Scoped, expiring, revocable. Session keys expire and are revoked automatically on any new device, credential change, recovery, or risk event on a payee in scope. A dormant automation cannot outlive the trust it was granted under.
5. Every automated figure reconciles. An automated transfer is confirmed by reading state back, never by trusting a receipt. A rule reports "paid" only when the balance actually moved.

The AI's role, and its limit

Programmable money is where an assistant earns its place: it can read a user's own cashflow and propose a rule in plain language, "you pay this landlord every month, want me to automate it within a 1,200 cap?". What it produces is a StandingIntent draft shown on the normal review screen. The human arms it under Tier 4 authentication. The AI cannot arm a rule, cannot sign, and cannot mint a session key; its egress to the relayer is blocked at the infrastructure level (AI architecture). The assistant makes automation legible; the kernel makes it safe.

Status

Designed The session-key validator, the policy hook, and the intent model that programmable money is built on are specified and interface-complete. Scheduled autopay, auto-allocation, and delegated allowances are designed against these primitives. Planned Streaming, conditional payments, and the entire earn/borrow/tokenised-asset frontier are planned and, where regulated, gated on licensed partners. Nothing here handles real customer funds today; the system stays on testnet until the checklist in the threat model is met.