[DeFi][FIN-28] Independent third-party extensions and adversarial integration corpus #78

Parent umbrella: #43. New FIN work-item: FIN-28. Planning only; no implementation is claimed.

Plain-language explanation

The extensibility system is useful only if another developer can build a meaningful programme without editing the compiler or the pool kernel. Malicious examples must also demonstrate that permission boundaries actually hold.

Mermaid walkthrough

flowchart LR
A["Third-party authored extension"] --> B["Independent package build"]
B --> C["Attach to admitted pool policy"]
C --> D["Execute real trade/state transition"]
D --> E["Hostile mutation and rejection tests"]
E --> F["Published reusable integration evidence"]

Implementation layer: External protocol packages + security integration evidence.

Dependencies / staging: #69 FIN-19 lifecycle hooks, #70 FIN-20 fees, #71 FIN-21 custom accounting; #73 FIN-23 oracle; #74/75 position/router where relevant; #56 orders for asynchronous example.

Detailed design and security review

Why an independent extension corpus matters

A framework that only supports extensions authored by its maintainer may hide hard-coded protocol assumptions. This issue requires genuinely independent packages using only public source interfaces, existing compiler, generated builders, exact dependency admission and transaction verification. An extension written correctly is not an audit of other extensions; include hostile variants.

Required reference applications

1. A stateful permissioned fee hook with authorised dynamic update and rejecting non-authorised traders.
2. A check-only before-swap hook that cannot return a financial debit.
3. A return-delta extension that charges/rebates within limits and a separately modelled alternative pricing curve.
4. An optional authenticated observation hook whose freshness/source contract is honestly declared.
5. A multi-pool hook referencing different pool identities without accidentally merging custody or state.
6. An asynchronous order/claim flow that creates an enforceable obligation and later settles or cancels it; do not call the initial step a completed swap.

Independent delivery sequence

Freeze public package boundary and assign an integrator not responsible for implementing the kernel. Record setup steps and generator versions from a fresh source checkout; prohibit hand-editing emitted ELF or hand-replacing compiler-owned witness bytes. Independently build and deploy (locally/selected admissible chain), construct real transactions, then deliberately mutate hook code/permission, operation order, returned deltas, settled balances, witness values and state successors.

Adversarial matrix

Acceptance report

Provide independently reproducible code, toolchain, signing/admission/VM vectors, signed/unsigned transaction identities, owner-by-owner settlement tables, failures at intended paths and manual DX interventions. Every accepted example must be reusable without compiler changes. Distinguish independent useability, automated checking and a real independent human security review.

End-to-end security flow

flowchart TD
    E["Outside developer authors extension"] --> P["Build normal CellScript package"]
    P --> A["Bind exact hook identity and permission"]
    A --> T["Execute authentic pool transaction"]
    T --> N["Mutate authority, bytes and financial deltas"]
    N --> F["Record valid/rejected VM evidence"]

General audit and release criteria

• This work is confined to ordinary CellScript protocol packages, tested maths, authenticated state and existing off-chain SDK/adapter boundaries. No application action name can authorise a finance-specific grammar, VM or compiler feature.
• Freeze selected schema/domain/operation budget, accountable implementer, independent human review disposition and valid/late-invalid resource ceilings. Any missing generic language primitive must have its own small business-neutral issue and independent-machine verification.
• Execute authentic full CKB transactions with all required Lock and Type groups, preserve original state continuity and distinct off-chain/VM/node/deployment evidence. Retain exact source, compiler/checker, artifact, CellDep, transaction and chain identities. Never claim a deployed or audited result without that evidence.

Design and delivery

• Publish independent stateful fee, return-delta charge, custom-curve, optional observation, permissioned-access and asynchronous order/claim extensions as ordinary packages.
• Exercise same-manager multi-pool extension where admitted; require exact source, code, ABI, authorisation and resource limits.
• For asynchronous settlement, create an enforceable persistent order or claim with distinct later fulfilment/cancel/recovery—not fictitious synchronous finality.
• Introduce deliberately malicious versions (false return, pool substitution, unauthorized debit, recursive misuse and resource exhaustion), with actual on-chain rejection or explicit unsupported scope.

Acceptance criteria

• A developer outside the implementer group builds a nontrivial stateful hook from public package/SDK APIs without compiler or kernel patches.
• At least one custom price, fee, observation and multi-pool integration runs in full CKB transactions.
• Unauthorized hook, malicious delta, wrong identity, omitted callback, replay and resource attacks reject at intended enforcement checks.
• Documentation distinguishes safe system permissions from the economic correctness of arbitrary third-party hook algorithms.

Security / scope boundary: Independent functional reproduction is not a completed human security audit and cannot establish correctness of all conceivable extensions.

General implementation and acceptance rules

• Issue status: proposed. Identify owners, reviewers and any actual review disposition explicitly; no release/deployment permission is implied.
• Deliver these semantics in ordinary CellScript protocol packages, standard library helpers or existing SDK boundaries. New compiler semantics require a separate demonstrably business-neutral failure case and checker/ABI/diagnostics contract.
• Freeze input/step/byte/cycle/capacity budgets, test genuine and hostile final CKB transactions with every required Script group, and archive pinned source/build/dependency/transaction/model identities and applicable gates.

Verified dependencies and implementation sequencing

Entry prerequisites: #69, #70, #71, #73.

Optional profile integrations: #74, #75, #56.

Unblocks / consumed by: #79, #60.

Reason for this sequence: External independent packages must be built without compiler/kernel patches. An asynchronous operation returns a real persistent obligation, not an immediate settled swap.

Dependency links are explanatory; they do not mark code as implemented, grant a reviewer waiver or set native GitHub issue blockers.