[DeFi][FIN-16] Ordered multi-operation settlement with per-user asset deltas #66

Parent programme: #43. Capability work-item FIN-16 (proposed; no new compiler/release commitment).

In plain English

One transaction may combine several pool actions and temporarily reuse proceeds. It must nevertheless prove the correct intermediate order and settle every user's actual debts before accepting the final state.

Visual explanation

flowchart LR
A["Bounded ordered operations"] --> B["Check each logical state"]
B --> C["Accumulate deltas per user and asset"]
C --> D{"All obligations settled?"}
D -- Yes --> E["One valid final successor state"]
D -- No --> X["Reject transaction"]

Primary layer: Settlement protocol and executable state-transition verification.

Dependencies: #61 FIN-11 pool architecture, #52 custody, #53 maths; final range-based integration after #65 FIN-15.

Detailed design and security review

The key distinction: accounting versus CKB execution

A single CKB transaction consumes old Cells and creates final output Cells. It does not spend an output it has just created. An ordered multi-operation programme therefore requires authenticated logical intermediate balances or a checked state-transition transcript; the actual on-chain transition is from old Cells to final successors. Intermediate claims are never spendable Cells during that transaction.

State and ledger model

Specify finite operations (pool swap, add/remove liquidity, donation, claim mint/burn, settlement) and record each participant's signed delta by complete asset identity and pool/owner scope. Define positive/negative sign semantics, operation ordering, who may clear a credit, which parties must sign, and when a third-party payment is permitted. Distinguish real token conservation from book liabilities and explicit capacities. The coordinator must not become an omittable off-chain helper: identify the concrete Script(s) that reject the transaction if any required debt or step is missing.

For every admitted asset A and participant P, the final net balance must be derived from all authorised operations exactly once. A positive delta belonging to Alice cannot implicitly pay Bob's debt without an authenticated delegated payment. A pool's obligations cannot be netted against an unrelated pool merely because both use the same token type.

Implementation sequence

1. Freeze exact operation transcript ABI, maximum count, account/asset cardinality, signed-domain overflow and error taxonomy. Start with two swaps over distinct pools and one sender.
2. Implement on-chain re-derivation of final deltas and exact intermediate pool states; bind stage-to-stage roots or tuples, not unchecked witness statements.
3. Integrate same-pool repeated operations while consuming the real predecessor pool Cell only once, yielding exactly one genuine final successor with corresponding reserves/ticks/fees.
4. Admit settlement-on-behalf and explicit positive-credit forfeiture only through declared user permission; add claim-funded operations after [DeFi][FIN-17] Fully backed transferable multi-asset custody claims #67.
5. Validate unrelated fee/change Cells and multiple independent signers in complete CKB transactions.

Attack matrix

Acceptance evidence

Independent double-entry ledger computes every delta and end-state. Test no-hook constant-product operations first, then range state and extensions. Record completed operation count, all-group execution, fee/claim/capacity balance sheet, worst-case cycles and transaction bytes.

State and execution flow

flowchart TD
    I["Authenticated real input Cells"] --> O["Ordered logical operations"]
    O --> D["Recompute per-owner / asset delta"]
    D --> B["Bind all intermediate pool transitions"]
    B --> N{"Each authorised obligation zero or settled?"}
    N -- No --> X["Reject"]
    N -- Yes --> F["Validate real final output Cells"]

General implementation, evidence and release policy

• Preserve business-neutral CellScript semantics: exact Script handles, typed transaction views, resource ownership, bounded execution and independent machine checking. Missing general primitives require separate, narrowly scoped issues and actual failing use cases.
• Freeze chosen data/ABI/profile, maxima, code deployment and review disposition before implementation admission. Record positive and hostile CKB-VM tests over complete transactions with correct signature setup, exact ELF/CellDep identities, state predecessors/successors and separate costs for VM cycles, witness bytes and occupied capacity.
• Builder checks and ProtocolBundle dry-runs are helpful but do not replace on-chain authority. No automatic public deployment, external audit claim or core compiler release follows from a completed protocol issue.

Implementation plan

• Define bounded, authenticated operation transcript and intermediate logical state for swaps, liquidity changes, donations, claims and payments; final CKB transaction consumes actual old Cells only and creates actual final successors.
• Track debit/credit per user and complete asset identity; specify settle-on-behalf, take, positive-credit forfeiture and same-pool repeated operations under explicit consent.
• Bind final balances and fee/backing liabilities to authorised real Cells and every required Script group; user-specific netting must not legitimise unpaid obligations.

Executable acceptance

• Swap→liquidity and remove→swap→re-add with a bounded repeated pool pass, with exact intermediate and final economic states.
• Wrong operation order, invented intermediate value, missing operation, hidden negative delta, different-owner debt offset and duplicate payment credit reject.
• A capital-reuse transaction closes all obligations under explicitly declared fee and custody semantics; an unpaid variant rejects.
• Independent model and full-transaction CKB-VM agree on final balances, signed operation intent, Script identities and frozen execution bounds.

Boundary: No EVM transient storage opcode, no cross-contract synchronous call and no claim that a newly created output can be spent within its own transaction.

Acceptance policy (all FIN work)

• Status: proposed. Implementer/reviewer unassigned; do not represent an unperformed audit as completed. Freeze versioned API, threat and bounded resource contracts first.
• Core compiler remains protocol-neutral: use ordinary CellScript data types, functions, actions, CKB views and existing generated builders. A demonstrated general-language failure requires its own business-neutral issue.
• All accepted proofs require exact source/compiler/checker/CellDep/transaction identities, independent financial models, hostile full-transaction cases and relevant dev/CI/backend gates. Node/public deployment claims remain separate. No release milestone is inferred.

Verified GitHub dependency links

Early kernel: #61, #52, #53. Final integration: #65. Downstream: #67 claims, #68 native CKB, #70/#71 fees and hooks, #74/#75 manager and router.

These are planning links, not executed acceptance or formal GitHub blocking relationships. Parent: #43.

Verified dependencies and implementation sequencing

Hard prerequisites: #61, #52, #53.

Additional final integration prerequisite: #65.

Unblocks or integrates with: #67, #68, #70, #71, #74, #75.

Technical dependency note: An initial ordered ledger can proceed before #65, but final cross-tick integration needs its accepted step/state contract. Verify logical intermediate states rather than pretending to spend transaction-created outputs.

This is a documented logical dependency, not a native GitHub blocking relationship or implementation acceptance.