Skip to content

[DeFi][FIN-07][M3] Settle an order against an AMM with enforced asset flows #57

Open

Description

@a19q3

Implementation ownership — protocol-first, no finance-specific compiler feature

Primary implementation layer: application settlement protocol and transaction composition, backed by existing ProtocolBundle/CKB adapter. settle_order, a pool leg, and payment allocation are not core-language primitives.

Implementation shape: use already implemented #54 pool and #56 order scripts, compose their real input/output state and token transfers in one CKB transaction, and have each relevant Type/Lock Script validate its own authority and economic obligations. Use #9/#10/#11 for exact-bundle metadata, role correspondence, canonical construction and all-group preflight. CKB provides atomic transaction validity; no new VM facility is needed to "call" the pool from the order or the order from the pool.

Acceptance interpretation: a builder that omits optional preflight cannot bypass on-chain asset-flow, recipient, pool reserve or order pricing checks. Shared-output allocation and routing stay in FIN-08, not compiler semantics.

Compiler-change gate (all FIN work): This issue does not authorise finance-specific grammar, IR, opcodes, codegen branches or hidden protocol semantics. First try existing general CellScript constructs. Any genuinely missing general capability needs a minimal failing application, a non-financial use case, its own narrow issue and independent checker/ABI/resource/gate acceptance as required by #43 §2.2. Application correctness and builder convenience are distinct from language support.


Umbrella: #43 FIN-07/M3. Owner roles: settlement protocol + execution evidence; reviewer unassigned. Status: proposed.

Hard dependencies

Scope

  1. Implement [DeFi][Application/Protocol] EVM-class finance on CKB with CellScript #43 C1: one authentic order interacts with one authentic constant-product pool, with distinct payment outputs per obligation. Define which asset flows to maker, taker, reserves, LP/pool state and capacity owner and precisely which Script validates each condition.
  2. Compose exact-deployment pool, token, order, escrow/custody and capacity/Lock groups within one canonical transaction, including unrelated Cells without silently incorporating their value into the accounting.
  3. Bind order price/cumulative entitlement to actual pool swap, fee/rounding, consumed state and required matching outputs. Ensure the protocol cannot reuse one payment amount for separate obligations merely because the builder considered it sufficient.
  4. Implement generated composition with ProtocolBundle and adapter, maintaining authoritative source/index identities, output correspondence and all-group preflight/signing parity.
  5. Record actual first-failure/enforcement domains: what current Script checks, what required peer groups check, what the builder checks, and what only the full CKB verifier establishes.

Acceptance

  • Frozen C1 transaction topology, roles, asset-flow equation, fee and capacity ownership, source/index/witness binding, exact deployment identities and numeric resource ceilings.
  • Authentic one-order/one-pool settlement executes across every Script group in the same actual transaction and updates each persistent state correctly, including unrelated Cell permutations admitted by the layout contract.
  • Underpayment, wrong recipient/asset, missing pool/order group, reserve mismatch, stale/forged order remainder, wrong pool, mismatched intermediate token amount and input/output substitution fail at the named on-chain boundary.
  • Independently checked reference economics, canonical builder/adapter bytes, replayable actual predecessor state, transaction hashes and explicit rejecting error layers archived.
  • Appropriate checker mutations and dev/CI/backend gates, full transaction cycles/stack/bytes/capacity budgets and scope-specific reviewer disposition recorded.

Non-goals: shared-payment outputs, cross-pool multihop and arbitrary role selection (#28/#29). Those belong to FIN-08 or separate generic work. Source: #43 §§5, 8–9 (C1), 11–12.

Dependency cross-links (confirmed GitHub issues)

Hard dependencies: #54 FIN-04 and #56 FIN-06, including actual pool/escrow economic rules and generated builders. Required by: #58 FIN-08; #57's C1 distinct outputs do not admit C2 shared-output credit allocation.

Umbrella dependency graph and authoritative financial acceptance: #43.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions