WhitepaperAgent wallets and accountable settlement

Agent wallets and accountable settlement

Agent budgets, funded credits, real-money claims and accountable batching of external settlement.

Conceptual designRURAL v0.0.0FIELD GUIDE

Status: proposed research appendix, 20 September 2026; WO-2026-006. Companion to RURAL — The Visible World (not published) and its typed economy. This is a conceptual contract, not an implemented wallet, provider approval or measured throughput claim. Database development remains paused. Provider rules below were checked on this date.

An agent should be able to receive a budget, reserve a purchase, account for useful work and return unused capacity without asking its owner about every small action. Millions of internal operations can become a much smaller collection of external settlement instructions. That requires an authoritative ledger and delegated spending policy; a balance displayed beside an agent is insufficient. Stripe would be an optional settlement adapter; local accounting and simulation must work without it.

1. Three meanings of a wallet

TypeWhat it representsExternal spending
Budget walletPermission to spend part of an owner's existing allocationOnly through that owner's authorized payment route
Service-credit walletAn issuer's obligation to supply specified servicesRestricted by the issuer's terms; no automatic cash redemption or third-party acceptance
Monetary walletA legally defined claim on a named issuer/custodian, backed by an approved funds arrangementOnly through the applicable regulated/provider arrangement

Recognition points remain a fourth, nonmonetary type. None automatically becomes another. An agent controls delegated authority; the contract names the responsible human or legal entity, beneficiary, issuer and custody relationship. Funds backing several agents must not be counted repeatedly.

Stripe Billing credits are designed for the business's own products and services. Their documentation prohibits generic stored-value use, third-party payments and linkage to digital wallets. Therefore, Stripe Billing credit grants cannot simply become universally spendable RURAL money. Stripe Billing credits.

2. Funding is an external fact

Keep RURAL's subledger separate from Stripe's provider ledger. Connect platform and connected accounts each have their own balances, including pending and available funds. RURAL's labels such as reserved or disputed are additional internal states; they do not create provider funds or protect them from provider restrictions. Reconcile by provider account, currency and transaction, never against one unexplained global total. Connect balances.

A funding intent records payer, beneficiary, amount, currency, refund terms and provider reference. A browser success redirect cannot make it spendable. Verified provider evidence advances the funding state; availability and the configured risk policy determine admission. Available card proceeds can still face later disputes.

Stripe platform top-ups serve permitted goods/services payment flows, require an approved profile and verified funding arrangement, and currently list the EU as private preview. They are not a guaranteed Croatian funding feature or a substitute for accepting an approved customer payment. Failed insufficient-funds transfers are not automatically retried after topping up. Platform top-ups.

3. Spending authority belongs outside the prompt

A delegation binds owner, agent, wallet, purpose, expiry, maximum per operation, rolling and total limits, approved counterparties, tools, currencies and risk class. Subdelegations consume their parent's remaining allowance. Concurrent children cannot each receive a fresh copy of the same allowance. Policy changes are versioned; emergency revocation blocks new commitments while reconciliation of existing obligations continues.

The purchase gate validates a structured quote and reserves its maximum authorized cost before execution. Price increases, new payees or altered deliverables require renewed authority. An untrusted page or tool result cannot increase limits. A compromised agent can propose a payment but cannot bypass the deterministic gate.

Funded wallets are separate from API credentials. An isolated connector obtains an opaque credential handle and a narrowly scoped execution permit. Secret keys, card data and unrestricted payment tokens never enter prompts, ordinary graph records or exported game snapshots. A provider's usage bill may exceed an estimate: enforce hard provider limits where available and disclose residual exposure.

4. Exact accounting and reservations

Every monetary or transferable-credit journal transaction balances debits and credits for each asset. Define denomination, instrument/issuer where applicable, precision and terms; EUR, USD, service credits and points cannot be added together. Use checked integers or fixed decimals. Foreign exchange has explicit priced legs, fees and rounding accounts. Issuance and destruction post against issuer accounts.

Under a proposed approved customer-funds arrangement, a EUR 100 funding receipt with EUR 3 fees could debit processor receivable EUR 97 and fee expense EUR 3, while crediting customer liability EUR 100. This explicitly makes the operator bear the fee; it must supply any backing shortfall before releasing the full allowance. A different contract must post the different obligation, not silently shrink the customer's balance. Final chart-of-accounts and recognition policies require accounting review.

Reservations reclassify available liability into reserved liability atomically. Successful billable delivery moves the accepted amount to the appropriate service or supplier obligation and releases the remainder. Failed work does not automatically imply zero cost: accepted cancellation and partial-delivery terms decide the posting. Expiration releases only reservations whose external outcome is known.

Funding-pending, available, reserved, payable, settlement-pending and disputed are distinct positions. They are not six copies of money. A wallet balance is a projection over postings; reservations, unique business identifiers and balance checks commit together. Corrections append compensating entries with original references. No historical amount is edited to make reconciliation pass.

5. Branches cannot clone purchasing power

The real settlement ledger has one authoritative domain independent of recursively branched workspaces. A branch sees a revision of its financial history and can calculate scenarios, but cannot fork spendable money. Simulation assets and receipts carry an unexchangeable simulation domain.

Real spending from two branches competes against the same live allowance. Merging branches merges proposals, never replays completed purchases. Restoring a database backup must start with external dispatch disabled and reconcile against newer provider activity before spending resumes; restoring yesterday's receipt set cannot permit yesterday's payout again.

Offline work may estimate costs or queue intents. Real offline spending requires a separately proven protocol preventing double spending; copied budgets or signed receipts alone cannot supply that guarantee.

6. A batch is a manifest of obligations

The settlement planner selects eligible, uncontested obligations at an explicit cutoff. Group by legal payer, beneficiary, asset, provider account, payment rail and settlement window. Apply contractual minimums, deadlines and holds; preserve each obligation's identity and allocation within an immutable batch manifest. An obligation belongs to at most one active settlement instruction. Later corrections enter a new adjustment batch.

Only legally and contractually eligible claims may be netted. Unrelated owners, currencies or custodians cannot cancel one another merely because arithmetic permits it. Gross activity, invoices, fees and allocations remain inspectable after netting.

Batch external tools only where their supported semantics permit it. Preserve per-item authorization, inputs, ordering, errors, cancellation and receipts. Ten thousand inference jobs sharing a transport batch still consume and incur charges for their work. Immediate fulfilment and expiring quotes cannot wait for a later financial settlement window.

Connect supports combining charges into transfers and splitting charges across recipients, subject to permitted flows and regional restrictions. A Connect transfer moves value between Stripe accounts; a payout moves it to an external account. The local batch may therefore require several provider objects. Separate charges and transfers.

Stripe manual payouts are not escrow. Its current general holding limit outside the US and Thailand is 90 days; a batching policy must honor the applicable deadline rather than accumulate funds indefinitely. Manual payouts.

7. Durable intent, uncertain execution

Posting the commitment and its outbox intent is one local transaction. A worker subsequently executes the exact versioned provider request outside the publication lock. The intent binds environment, provider account, payee, asset, amount, manifest digest and idempotency identity.

Before dispatch, validate current authority, permit expiry and the exact request again. Dispatch admission and revocation have an explicit serialized order in the live authority domain. Revocation that wins this ordering blocks undispatched revocable work; release its reservation only after confirming that no outside obligation exists. Once dispatch wins, a request may already have escaped: report the in-flight identity and attempt supported cancellation, without promising recall. An already irrevocable contractual obligation is recorded separately and requires an explicit servicing mandate. Expired or revoked agent authority never suppresses reconciliation of work already submitted. This is a local authority boundary, not an atomic lock on the external provider.

Track prepared, dispatching, provider-accepted, settlement-pending, settled, rejected and unknown-outcome separately. Settlement means the evidence required by that rail and contract, not irrevocability against every later return. A timeout after submission leaves funds reserved. The worker queries and reconciles before retrying or releasing them. Cancellation of local work cannot cancel a payment already accepted remotely.

Stripe retains an idempotent result, including server errors, but keys may be removed after at least 24 hours; reuse after pruning can create a new request. RURAL therefore needs durable business-level deduplication beyond Stripe's retention window. Retries use the original parameters and key while valid; unresolved older attempts require reconciliation, never a freshly invented key. Idempotent requests.

8. Evidence, returns and solvency

Verify webhook signatures over raw bytes, enforce replay tolerance, and bind events to the expected account and live/test environment. Durably admit an authenticated event before acknowledging it, then process asynchronously. Duplicate deliveries and independently generated equivalent events cannot post twice. Out-of-order arrivals cannot roll a terminal business fact backward; retrieve authoritative objects when evidence conflicts. Stripe documents duplicates and unordered delivery. Webhook contract.

Periodic reconciliation compares internal postings, provider balance transactions, transfers, payouts and bank evidence. Unexplained differences enter a suspense account and block affected spending. Reports expose liquidity, outstanding liabilities, reserves and reconciliation age separately. A balanced journal can still describe an insolvent operator.

For indirect Connect charges, Stripe debits the platform for refunds, disputes and associated costs. Refunding a separate charge does not automatically reverse its transfers. The proposed operator must assign loss liability, maintain liquidity and handle failed recovery; a payment marked paid is not protected against all later claims. Refunds and disputes.

9. What a million operations could become

Illustrative arithmetic, not a benchmark: one million accepted billable operations across 20 suppliers, two currencies and four daily windows yield at most 160 nonempty supplier/currency/window groups if all other grouping conditions match. That is 6,250 internal operations per group on average when all groups are populated. Additional legal entities, holds, size limits, reversals and payment routes increase external work. Transfers and bank payouts remain separate; incoming funding and its costs remain separate too.

At an assumed 1 KiB of journal and receipt data per operation, one million operations generate about 0.95 GiB before indexes, replication and additional lifecycle postings. One million per day averages only 11.6 operations/second; it says nothing about burst capacity or tail latency.

Batching can reduce fixed per-instruction costs, not eliminate economic costs. Croatia's published Connect pricing for platforms handling pricing currently includes EUR 2 per active monthly account and 0.25% plus EUR 0.10 per payout; other routing, processing, currency and optional-service charges can apply. These are dated examples, not a quotation or a complete cost model. Croatia Connect pricing.

10. Capacity and jurisdiction are gates

Proposed performance work must measure admitted business operations, actual postings, durable receipt latency, hot-wallet conflicts, recovery time and reconciliation lag. Parallel partitions help independent wallets; one shared scarce balance still needs serialized conflict resolution. Cross-partition transfers require a defined atomic protocol, not eventually consistent spending checks. Durable batching must never acknowledge an unfunded or uncommitted spend.

In the EU/Croatian framework, money received and represented by a claim accepted by parties other than its issuer can fall within electronic money. Croatia's Act governs authorized issuers, redemption and HNB permissions; limited-use exceptions are conditional. Calling a transferable claim a credit does not settle classification. Before real money, choose the legal issuer/custodian, regulated partner, safeguarding model, redemption terms and allocation of fraud/insolvency liability. This is a design gate, not a legal conclusion or authorization. HNB-hosted Electronic Money Act, Articles 3–7 and 12; unofficial consolidated English text.

11. Future acceptance and the DEV-25 demonstration

The future game should show synthetic wallets as accountable reservoirs and payment pipes as stateful obligations. A scenario funds a simulated allowance, launches competing agents, reserves tool budgets, accepts partial work, groups supplier claims and injects a lost response, duplicate webhook and subsequent dispute. Opening a pipe reveals authority, postings and evidence. No real account, payment credential or funds movement is needed.

Acceptance must prove per-asset conservation, concurrent overspend rejection, atomic reservations/outbox, stable retries, branch/restore isolation, partial batch failures, late corrections, webhook replay resistance and recovery after each durable boundary. Test frozen provider accounts, unavailable banks, expired delegations and depleted reserves. Demonstrate that a million synthetic operations produce the expected audit totals and settlement manifests before making any capacity claim. Real funding follows separately approved provider and financial-product gates.

Find your way.