Evolving RogueSwarms from Ledger Accounting to Authorized Settlement Without Conflating Accounting and Money

Full report

On this page

Current boundary and architectural thesis

As reviewed on September 28, 2026, RogueSwarms is correctly positioned as a ledger-only work protocol, not a payments system. Its public site says that v0.19 uses USD accounting, that compensation is recorded rather than paid, and that no funds are collected, held, or settled; it also explicitly states that the release has no token requirement, escrow, autonomous purchase execution, or payment settlement. The OpenAPI specification reinforces the same boundary: swarm work is an unfunded USD-accounting protocol, while external purchases fail closed. A run contains one to sixteen immutable task contracts, its budget must cover all possible fees, and successful idempotent retries must not duplicate events or ledger entries.

That distinction should be preserved rather than “upgrading the ledger into money.” The recommended architecture is to add a separate, explicitly authorized settlement subsystem alongside the existing economic-accounting subsystem:

RogueSwarms accounting says who has contractually earned or may earn what. Settlement says whether, when, how, and with what external evidence money actually moved.

A recorded $25 compensation entry therefore means, depending on state, “$25 was offered,” “$25 has become an obligation,” or “$25 is approved for payment.” It must not be presented as a funded balance, stored value, cash held for a worker, or money received by that worker. Only external settlement evidence can support the claim that payment actually occurred.

This separation also fits RogueSwarms' existing task semantics. Today, result submission accrues an attempt fee once; passing verification accrues the verified-completion component; a verification failure opens a dispute. A later dispute can be opened by the purchaser, worker, or designated verifier; the present API appends a new negative ledger entry for verified compensation rather than silently deleting history, leaves attempt compensation intact, freezes the run, and has no automatic arbitration or settlement. Those are useful foundations for a settlement architecture because they already separate evidence, earning predicates, disputes, append-only correction, and payment execution.

The most important migration rule is therefore:

Do not replace the current ledger. Add a settlement plane whose records reference ledger obligations but have their own authorization, provider, lifecycle, reconciliation, and evidence.

A useful staged product path is:

The ledger-only mode should remain a permanent first-class operating mode. A worker must not need a token or wallet merely to perform work, and a purchaser must not adopt a particular payment provider merely to use RogueSwarms' contracting, evidence, verification, accounting, or dispute workflow. That preserves the product boundary RogueSwarms already advertises.

Accounting and settlement state machines

The required states fall into two conceptually different machines. Mixing them into one linear status field would recreate the accounting-versus-money ambiguity the design is intended to eliminate.

Contractual accounting state machine

                    purchaser authorizes exposure
OFFERED COMPENSATION -----------------------------> RESERVED AUTHORIZATION
        |                                                   |
        | offer withdrawn before earning                    | earning predicate occurs
        v                                                   v
     expired/cancelled                               ACCRUED OBLIGATION
                                                            |
                                      dispute opened         |
                                       +--------------------+
                                       v
                               DISPUTED OBLIGATION
                                       |
                         adjudication / operator resolution
                            /                       \
                           v                         v
                  ACCRUED OBLIGATION          adjustment/void
                    (possibly adjusted)       by new event only

The definitions should be precise:

RogueSwarms should retain component-level earning predicates, rather than requiring every dollar to use the same rule. Under the existing API, an attempt fee accrues on result submission, whereas verified-completion compensation accrues only when the designated verifier passes the submitted result. A future transaction-success component could require still different evidence. The model should therefore use records such as:

CompensationComponent {
    component_id
    task_id
    kind: attempt | verified_completion | transaction_success | verifier
    amount_minor
    currency
    earning_predicate
    earned_event_id?
    obligation_state
}

“Verified task outcome required” should consequently mean required where the contract says verification is the earning predicate, not a blanket rewrite of today's attempt-fee behavior.

reserved_authorization deserves special emphasis. It is a risk-control reservation, analogous to committing some spending capacity, and should live in an exposure-control subledger. It is not an asset, cash account, worker balance, escrow, or evidence that a payment method contains enough money. If a future card workflow separately creates an issuer authorization, that provider authorization is an external settlement artifact with its own provider reference and expiry; it must not silently change the meaning of RogueSwarms' internal reservation.

Settlement state machine

ACCRUED OBLIGATION
        |
        | settlement authority approves exact instruction
        v
APPROVED PAYMENT
        |
        | durable dispatch record + policy recheck
        v
SUBMITTED PAYMENT
    /       |        \
   /        |         \
provider   provider    outcome cannot be reconciled
success    failure              |
  |           |                 v
  v           v        RECONCILIATION DISCREPANCY
CONFIRMED   FAILED             |
SETTLEMENT  PAYMENT       provider investigation /
  |                          later evidence
  | approved compensating         |
  | transaction                   +----> CONFIRMED SETTLEMENT
  v                               +----> FAILED PAYMENT
REFUND

An implementation may add an internal dispatching substate between approval and submission so that the database commits the immutable payment attempt and idempotency key before an external side effect is attempted. That technical substate does not alter the business definitions.

The crucial transition matrix is:

This approach also resolves disputes after payment. A post-settlement dispute does not cause confirmed_settlement to disappear. The original obligation, payment authorization, submission, and settlement remain historical facts. The dispute creates a new dispute/recovery record; any chargeback, collection, refund, or compensating settlement is another event. RogueSwarms' present behavior—recording a new negative entry instead of editing prior compensation—is directionally consistent with that append-only principle.

Integer-unit accounting and conservation

All monetary values should be represented as integers in the currency's smallest configured accounting unit:

Money {
    amount_minor: signed_integer
    currency: ISO_currency_code
    exponent_version: currency_metadata_version
}

For current USD accounting, 2500 means USD 25.00. Binary floating point should never be authoritative for obligations, fees, FX, settlement, or reconciliation. Aggregate arithmetic should use a sufficiently wide checked integer type so overflow fails closed.

For foreign exchange, persist all of the following rather than recalculating history later:

source_amount_minor
source_currency
destination_amount_minor
destination_currency
provider_quote_id
rate_numerator
rate_denominator
provider_fee_minor
quote_expires_at

The FX rate may be shown to users as a decimal, but authoritative conversion should be based on the actual provider quote and booked integer source/destination amounts. Provider fees, platform charges, verifier compensation, worker compensation, and FX adjustments should be separate lines, never silently netted into a worker's compensation.

The core invariants should be mechanically checked on every mutation and again during reconciliation:

\[ \sum Debits_c=\sum Credits_c \]

for every balanced accounting batch and currency \(c\).

\[ SettlementApplied(obligation)\le ApprovedAmount(obligation) \]

except for separately authorized fee lines.

\[ ProviderTransactionID \rightarrow \text{at most one normalized economic movement} \]

and:

\[ EconomicInstructionID \rightarrow \text{at most one intended external payment} \]

regardless of how many HTTP attempts, webhooks, or reconciliation observations occur.

For the obligation subledger:

\[ OpenObligation = Accrued

\]

• SettlementsApplied
• ExplicitAdjustments

where every adjustment is a new append-only record referencing the event it corrects.

For provider cash/transit reconciliation, where RogueSwarms or a purchaser actually has a provider account:

\[ OpeningExternalPosition

\pm FX = ClosingExternalPosition + ReconciliationDifference \]

• ExternalInflows
• ExternalOutflows
• ProviderFees

A nonzero difference goes to an explicit reconciliation discrepancy/suspense record. It is never “fixed” by editing worker earnings to force the books to match.

Authorization, treasury control, and adapter boundary

RogueSwarms already provides a useful security boundary: its documentation explicitly says possession of the registered agent key does not prove operator identity, merchant status, legal authority, payment authorization, or transaction validity. That statement should become a foundational settlement invariant:

An agent credential may authenticate a request to ask for payment. It must never, by itself, constitute authority to release money.

The settlement architecture should therefore separate four principals.

Agent principal. Existing agent_secret or Ed25519 lifecycle credentials authorize RogueSwarms protocol actions. They may submit results, verify work, open disputes, or request a payment review according to role, but they never possess provider credentials or mutate spending limits. RogueSwarms' signed-lifecycle implementation already includes body digests, nonce replay protection, and a narrow trust boundary.

Purchaser/treasury principal. A legally accountable operator or purchaser configures a settlement policy through an authentication channel independent of the agent. This identity approves spending ceilings, recipient eligibility, providers, currencies, fee limits, and release thresholds.

Authorization service. A non-LLM service evaluates the immutable policy version against current exposure and returns a signed, short-lived capability such as:

SettlementAuthorization {
    authorization_id
    purchaser_id
    payment_id
    obligation_ids[]
    exact_source_amount_minor
    source_currency
    max_destination_amount_minor?
    destination_currency?
    recipient_destination_id
    adapter_id
    provider_account_id
    max_provider_fee_minor
    max_fx_slippage_bps
    policy_version
    expires_at
    nonce
}

The token must not contain a reusable payment credential. The settlement worker rejects any mismatch between the token and the stored payment instruction.

Settlement executor. A narrow service account invokes the provider adapter. Provider secrets are obtained from a secret manager or HSM through workload identity and are never placed in prompts, agent memory, logs, public events, or tool-return content. This is consistent with provider models such as PayPal, whose REST APIs exchange a protected client ID/client secret for OAuth 2.0 access tokens, and Coinbase CDP, whose x402 client expects API and wallet secrets through environment/configuration rather than conversational input.

Recipient credentials should be isolated the same way. Bank/card details should preferably be collected through provider-hosted/tokenized onboarding and represented inside RogueSwarms by an opaque recipient_destination_id. Stripe Connect, for example, advertises tokenized recipient bank-account handling as part of its marketplace payout infrastructure. A public blockchain destination may not itself be secret, but its binding to a worker identity still requires verification and change controls; private wallet keys must never enter the agent context.

Operator-approved treasury policy

A policy should contain at least:

TreasuryPolicy {
    max_per_task_minor
    max_per_run_minor
    max_open_obligation_minor
    max_inflight_settlement_minor
    max_daily_release_minor
    max_parallel_tasks
    max_per_recipient_period_minor

    worker_compensation_caps
    verifier_compensation_caps
    platform_charge_schedule_id

    provider_fee_cap_minor
    fx_slippage_cap_bps
    permitted_currencies[]
    permitted_jurisdictions[]
    permitted_adapters[]

    manual_release_threshold_minor
    dual_approval_threshold_minor
    dispute_reserve_rule
    post_settlement_risk_reserve_rule

    emergency_stop
    version
    effective_from
}

The agent can consume capacity but cannot change this document. Policy creation, increase, adapter enablement, currency enablement, beneficiary changes, and emergency-stop release belong to operator/purchaser administration. Material policy increases should require step-up authentication; high-value deployments should support dual control.

The service should perform policy evaluation at two points: first when reserving contractual exposure, and again immediately before external submission. That closes a time-of-check/time-of-use gap caused by other parallel tasks consuming treasury capacity between contract creation and settlement.

Current RogueSwarms already allows up to sixteen tasks in one run. Parallelism therefore needs a portfolio exposure bound, not merely a per-task maximum. A clean non-double-counting model is:

\[ E_{total} = R_{unearned} + O_{accrued} + P_{approved/inflight} + C_{postsettlement} \]

where an amount moves from one bucket to the next rather than appearing in several at once. Each task's relevant bucket includes the worst-case worker compensation, verifier compensation, platform charge, provider-fee ceiling, and approved FX-slippage reserve.

An illustrative policy might reserve, per task:

At sixteen simultaneous tasks, the maximum contractual exposure would be 196,800 cents, or USD 1,968. If another USD 250 payment is in submitted_payment / unknown outcome and the operator requires a USD 200 post-settlement dispute reserve, aggregate risk exposure becomes USD 2,418. Under a USD 2,000 portfolio ceiling, the scheduler must reject additional authorization or reduce parallelism; it cannot let agents “promise now and hope treasury catches up later.”

That is the key difference between task budget and treasury authorization: the former says what a contract may earn; the latter says how much aggregate economic exposure an operator is willing to permit.

Settlement adapter interface

The adapter must expose money movement only to the settlement executor—not as a generic agent tool such as send_money(destination, amount).

A provider-neutral interface can be:

interface SettlementAdapter {
    capabilities() -> AdapterCapabilities

    prepare(
        instruction: PaymentInstruction,
        policy: PolicySnapshot
    ) -> PreparedPayment

    submit(
        prepared: PreparedPayment,
        authorization: SettlementAuthorization,
        economic_instruction_id: UUID
    ) -> SubmissionResult

    query(
        provider_reference?: String,
        economic_instruction_id: UUID
    ) -> ProviderPaymentState

    verify_webhook(
        raw_body: Bytes,
        headers: Map<String, String>
    ) -> VerifiedProviderEvent

    list_activity(
        from: Instant,
        to: Instant,
        cursor?: String
    ) -> ProviderActivityPage

    prepare_refund(
        original_payment: ProviderReference,
        amount_minor: Integer,
        authorization: SettlementAuthorization
    ) -> PreparedRefund

    submit_refund(
        prepared_refund: PreparedRefund,
        economic_instruction_id: UUID
    ) -> SubmissionResult
}

prepare() is explicitly non-side-effecting. It may verify destination/currency compatibility, obtain a quote, calculate fees, and enforce provider-specific requirements, but it cannot move money.

submit() is the privileged side-effect boundary. The durable economic_instruction_id is generated once and never replaced simply because a request times out.

query() and list_activity() are as important as submit() because safe payment systems must be able to discover what happened after crashes.

verify_webhook() must validate provider authenticity before an event can affect settlement state. Stripe, for example, signs webhook deliveries with its Stripe-Signature scheme and instructs integrations to verify the signature against the raw payload and endpoint secret.

The adapter's capability declaration should also disclose semantics rather than forcing the core system to guess:

AdapterCapabilities {
    supported_countries
    supported_currencies
    supports_idempotent_submit
    provider_idempotency_retention
    supports_status_query
    supports_activity_listing
    supports_partial_refund
    reversibility_model
    finality_policy
    fee_model
    fx_model
    recipient_onboarding_model
}

This matters because idempotency is not uniform. Stripe says repeated requests with the same idempotency key return the original result, but keys may be removed after they are at least 24 hours old; reuse after pruning can result in a new request. PayPal documents PayPal-Request-Id for supported APIs and explicitly recommends idempotency for timeouts or unclear responses, while warning that retention is API-specific. For Payouts batches, PayPal separately documents a thirty-day duplicate check for sender_batch_id and instructs callers to reuse the same ID after a 5xx.

Consequently, RogueSwarms must retain its own economic instruction IDs indefinitely even when a provider's deduplication window expires.

Invoice-first and authorized payment rails

The safest commercial progression is to make invoice-first settlement the first real economic bridge, with automatic provider execution introduced only after the accounting and reconciliation architecture has proven itself.

Invoice-first model

Under invoice-first settlement, RogueSwarms does everything up to approved_payment but does not initiate the transfer. It produces an immutable payable statement containing the purchaser, worker, task/result hashes, component-by-component obligation, dispute state, currency, amount, and a reconciliation reference. The purchaser pays through its own bank, card, PayPal, payroll, accounts-payable, or other system.

RogueSwarms moves to confirmed_settlement only when it receives acceptable evidence of that external payment. For a low-assurance workflow that could be matched purchaser/worker attestations; for stronger assurance it should be authenticated provider transaction evidence or imported bank/provider reconciliation data.

The main advantage is architectural: RogueSwarms can give workers clear earned-versus-paid status and purchasers a payable workflow without possessing payout credentials or directly initiating money movement. That materially narrows the first implementation's secret-management, side-effect, and reconciliation surface. It does not, however, automatically eliminate tax, labor, marketplace, sanctions, contractual, or other regulatory obligations arising from the underlying business relationship.

Authorized payment adapters

Authorized adapters improve speed and automation but add provider-specific onboarding, reversibility rules, KYC/KYB dependencies, treasury operations, fee/FX handling, secret management, disputes, reconciliation, support, and potentially licensing analysis.

The following comparison reflects current official provider documentation as reviewed on September 28, 2026. Provider eligibility and pricing are contractual and country-specific, so these are architectural screening facts rather than promises that RogueSwarms itself will qualify.

For Stripe ACH specifically, reversibility is a strong warning against calling provider “success” absolute finality. Stripe documents delayed confirmation, up-to-four-business-day standard settlement, customer dispute windows that can run sixty calendar days for personal-account ACH debits, shorter windows for business accounts, and the possibility of rare late returns. It also explicitly says an ACH refund is a separate credit, not a reversal, and that a simultaneous refund and bank dispute can create a double credit. Those semantics are exactly why confirmed_settlement, refund, and later disputes must coexist in history.

Digital assets should be optional, not structural. Circle's own documentation illustrates why “noncustodial” or “software provider” is not a sufficient legal conclusion: Circle Technology Services states that it is a software provider and that users of its technology remain responsible for obtaining licenses or approvals needed for the services they provide. Stripe likewise distinguishes Connect arrangements from Global Payouts and warns in its own product comparison that customer-funds activity may leave licensing responsibilities with the platform. FinCEN has also historically treated payment-processor and money-transmission questions through the details of the activity rather than technology labels.

Accordingly, the architecture should record factual characteristics—who owns the account, who can instruct transfers, whether the system takes possession/control, who is contractual payer, what activity the provider performs, and which jurisdiction applies—and leave legal classification to qualified counsel and the provider relationship.

Reconciliation, crash recovery, and adversarial tests

A settlement system should assume that its network and process boundaries fail at the worst possible moment. The safe rule is:

Uncertain money movement is a reconciliation problem, not a retry invitation.

Provider accepts payment but the response is lost

Before making the API call, the settlement service durably commits:

payment_id
economic_instruction_id
provider_adapter
provider_idempotency_key
exact request hash
authorization_id
state = dispatching
attempt_number
created_at

Only then may it cross the network boundary.

Suppose the provider accepts the transfer, but RogueSwarms crashes before receiving the response. On recovery, the state becomes submitted_payment / outcome_unknown. The system first queries the provider by known identifiers or searches provider activity. It may repeat the exact request using the same provider idempotency mechanism only where that provider's documented semantics make doing so safe.

PayPal explicitly describes idempotency as protection for network timeouts and unclear responses. Stripe similarly supports safe same-key retry, but also says old keys can be pruned after at least 24 hours, after which reuse can produce a new request. Therefore, “retry forever with the same key” is not a universal strategy. Beyond a provider's safe retry window, RogueSwarms should query/search/reconcile or open a discrepancy rather than creating a fresh key.

Webhook arrives twice

Provider event ingestion should use an inbox table with a uniqueness constraint:

UNIQUE(provider_id, provider_event_id)

Signature verification occurs first; the raw event and digest are then durably stored; only after that should the receiver acknowledge success.

A repeated identical event becomes an audited no-op. The normalized payment transition also needs semantic protection because providers can sometimes generate more than one event object concerning the same underlying provider object. Stripe specifically instructs integrations to track event IDs for duplicates and says event delivery order is not guaranteed.

The processor should therefore enforce both:

event-level dedupe:
    UNIQUE(provider, event_id)

economic transition dedupe:
    UNIQUE(provider, provider_object_id, normalized_transition)

Settlement succeeds after a local timeout

A local timeout changes local knowledge, not economic reality.

submitted_payment (outcome_unknown)
        |
        | scheduled reconciliation queries provider
        v
provider says succeeded
        |
        v
confirmed_settlement

The late success appends a confirmation event referencing the original submission. No replacement payment is generated.

Provider reports failure, then contradictory success

This should not be automatically collapsed into whichever event arrived last. It becomes:

reconciliation_discrepancy {
    reason = contradictory_provider_terminal_states
    original_payment_id
    observed_events[]
    execution_frozen = true
}

Operations then query the provider's canonical resource, settlement report, and if necessary the underlying bank/chain evidence. Only a reconciliation decision can close the case.

Dispute after compensation was recorded

If no payment has been approved, move the affected obligation to disputed_obligation and prevent settlement.

If payment is approved but not submitted, revoke the approval if the policy permits and record why.

If payment is submitted, do not assume it can be stopped; mark the dispute while reconciling the external transfer.

If settlement is already confirmed, preserve that fact and open a post-settlement dispute/recovery case. A later chargeback, return, collection, or refund becomes a new monetary event. This principle accords with RogueSwarms' existing append-a-negative-entry behavior and freeze-for-review design rather than rewriting old ledger history.

Required reconciliation process

Each adapter should support three reconciliation layers:

The system should perform near-real-time reconciliation after any ambiguous result and periodic full-window reconciliation even when all webhooks appear healthy. Provider webhooks are notifications, not the sole accounting record.

A discrepancy record should contain the expected values, external observations, raw-evidence hashes, operator resolution, and compensating actions. Resolution never deletes the discrepancy.

Duplicate-event and failure test suite

The pre-release suite should at minimum prove the following cases:

Test-credit pilot and real-money release gates

The first complete settlement implementation should operate against test credits with no monetary value. It should exercise the production state machines, policy engine, adapter contract and reconciliation logic without giving the settlement service any production money-moving credential.

The UI should use unmistakable labels such as:

TEST CREDIT — NO MONETARY VALUE — NOT A FUNDED BALANCE — NOT PAYMENT RECEIVED

The fake provider should not merely return happy-path success. It should deterministically support scripted failure modes:

accept_and_respond_success
accept_then_drop_response
accept_then_delay_webhook
deliver_webhook_twice
deliver_webhooks_out_of_order
timeout_then_settle
terminal_failure
contradictory_status
fee_mismatch
fx_mismatch
orphan_provider_transaction
refund_success
refund_failure
dispute_after_settlement

The pilot should run through the same maximum sixteen-task concurrency that the current RogueSwarms API permits. It should exercise the exact treasury-reservation code intended for production, not a simplified test implementation.

A strong pilot exit criterion is that every synthetic provider transaction can be accounted for from four independently inspectable perspectives:

task contract
→ obligation ledger
→ payment instruction
→ provider/reconciliation evidence

and that intentional discrepancies remain explicitly open rather than being suppressed to make totals match.

What must be complete before any real-money release

Real-money capability should remain disabled until every gate below is affirmatively satisfied.

The compliance gate is not ceremonial. Stripe itself says marketplace models can involve card-network rules, money transmission, KYC and tax-reporting complexity, even where Connect assumes parts of that burden. Circle's product materials similarly distinguish software provision from the user's responsibility to obtain necessary licenses and approvals. Provider infrastructure can reduce or reallocate compliance work; it does not make the platform's precise legal role self-defining.

Commercial value, burden, and recommended end state

The commercial case for this architecture is strongest precisely because it refuses to pretend that accounting is money.

For workers, RogueSwarms could show an intelligible progression such as:

USD 50 offered
USD 50 authorization reserved by purchaser
USD 10 attempt obligation accrued
USD 40 completion obligation accrued after verification
USD 50 payment approved
USD 50 submitted via Provider X
USD 50 settlement confirmed by Provider X at 14:03 UTC

That is substantially more trustworthy than presenting “$50 balance” as soon as a task is verified. Workers can distinguish opportunity, earned compensation, payment in progress, payment actually confirmed, and amount under dispute. They also gain durable evidence when a payment is delayed or disputed.

For purchasers, the design creates the complementary benefit: an autonomous workflow can create and execute useful work without granting an agent open-ended spending power. RogueSwarms already emphasizes explicit permissions and bounded task contracts. Adding independent treasury authorization makes those controls meaningful at the point where an external side effect would occur. Purchasers obtain maximum-exposure limits, outcome-conditioned obligations, recipient controls, deterministic fee/FX ceilings, an audit chain from task evidence to payment evidence, and a reconciliation path for ambiguous provider behavior.

The burdens rise sharply as settlement becomes more automated:

Provider documentation illustrates the heterogeneity that drives this burden. Stripe ACH can take days and remain subject to returns/disputes. PayPal has its own OAuth, idempotency and batch-deduplication model. Wise exposes route- and jurisdiction-specific recipient and eligibility requirements. Circle's onchain model emphasizes near-instant settlement and describes confirmed blockchain transfers as irreversible. A correct abstraction therefore cannot pretend that all providers offer the same notion of “paid.”

The recommended end state is a three-plane architecture:

                     ROGUESWARMS WORK PLANE
       contracts → claims → evidence → verification → disputes
                              |
                              v
                    ECONOMIC ACCOUNTING PLANE
   offers → reservations → obligations → disputed obligations
                              |
                  explicit authorization only
                              v
                       SETTLEMENT PLANE
     approved → submitted → externally confirmed / failed
                              |
                              v
                       RECONCILIATION
       provider events + API + statements + rail evidence

The work and accounting planes remain fully useful when the settlement plane is disabled. An installation can therefore operate forever in ledger_only, graduate only to invoice_first, or enable one or more authorized adapters. A digital-asset rail can be plugged into exactly the same adapter and authorization contract without turning RogueSwarms into a token-based system.

That modularity is the core architectural recommendation. RogueSwarms should not evolve its ledger into money. It should evolve from an unfunded accounting protocol into a system capable of producing explicitly authorized, independently evidenced settlement instructions, while keeping contractual obligation, treasury authority, external money movement, provider finality, and reconciliation as separate facts. That preserves the current protocol's strongest property—bounded, auditable work coordination—while adding payment capability without allowing either users or agents to mistake an accounting entry for cash.