[DeFi][FIN-17] Fully backed transferable multi-asset custody claims #67

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

In plain English

A user may keep an asset inside controlled custody and receive a transferable claim to that same asset. The claim must always be redeemable according to its stated policy and never duplicate pool principal.

Visual explanation

flowchart TD
A["Deposit authentic asset"] --> B["Reserve backing"]
B --> C["Mint asset-specific claim"]
C --> D["Transfer / use in settlement"]
D --> E["Burn claim to redeem"]
E --> F["Release correct backing"]

Primary layer: Claim-token / custody application protocol.

Dependencies: #61 FIN-11 authentic pool/custody identity; #66 FIN-16 settlement; #52 asset rules.

Detailed design and security review

Financial meaning and security invariant

An internal transferable claim is an enforceable liability denominated in a specific real asset, not a free-standing receipt label. If 100 authentic units are deposited and 100 claims minted, those units must remain reserved under a mandatory on-chain policy. Transferring a claim moves entitlement; it does not create another 100 underlying units. Claim redemption must burn or otherwise settle the corresponding entitlement exactly once.

Backing and authorisation ledger

Define a canonical ClaimId containing complete asset Type Script identity, custody policy and chain domain. Freeze amount widths, granularity, rounding, owner identity, approved transfer shapes, claim issuer/burn authority and any optional delegate. Publish a liability equation over every admitted class: available vault assets must cover all outstanding claims after accounting separately for pool principal, liquidity-provider fee entitlements, protocol fees, refunds and other encumbered reserves. If any backing can be reused among these classes, an explicit transfer/reclassification operation must update both sides.

Implementation steps

1. Implement genuine asset deposit and on-chain matched claim issuance, with exact custody and capacity funding.
2. Implement owner-authorised transfer/split/merge with unforgeable complete claim identity and amount conservation.
3. Integrate claim-funded settlement with [DeFi][FIN-16] Ordered multi-operation settlement with per-user asset deltas #66: debit an authentic outstanding claim and credit the intended trade/payment obligation only once.
4. Implement redemption and supply decrease, with auth, correct asset return, fees, dust/refund and optional clear/forfeit semantics explicitly frozen.
5. Independently test across two admitted assets, two owners and an unrelated pool to prevent cross-domain netting.

Security cases

Evidence

Use an independent balance-sheet model and full CKB multi-group tests, including malicious builders that omit optional SDK checks. Record vault occupancy, claim outstanding supply, backing amount, refunded CKB capacity and all exact deployment identities. Explicitly state the difference between a backed claim and a pool LP position.

State and execution flow

flowchart TD
    A["Authenticated asset deposit"] --> B["Reserved backing + claim supply"]
    B --> T["Owner transfer or authorised settlement"]
    T --> R["Redeem and burn claim"]
    R --> V{"Backing and supply remain equal?"}
    V -- No --> X["Reject"]
    V -- Yes --> O["Correct asset paid out"]

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 complete identity, backed supply and capacity ownership of multi-asset claims; distinct from LP shares, concentrated positions and ordinary off-chain balance labels.
• Implement deposit/mint, owner-authorised transfers, delegation, settlement use, burn/redemption and explicit credit forfeiture if admitted.
• Prove aggregate reserve backing excludes principal already reserved for other liabilities; account for claim fragmentation and fee/capacity separately.

Executable acceptance

• Two asset types and multiple holders complete deposit→transfer→settlement→redemption with exact conservation.
• Unbacked issuance, wrong owner, same-token identity collision, duplicated redemption, forged burn and spending LP-reserved backing reject.
• Claims pay for swaps or liquidity changes without simultaneously counting the underlying deposit as a second payment.
• Real CKB-VM all-group outcomes and the independent balance-sheet model agree under declared limits.

Boundary: Claim backing and redemption are protocol guarantees, not built-in coin balances or byte-level interface compatibility with another VM.

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

Core: #61, #66 and #52. Downstream: #75 action-plan routing.

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

Verified dependencies and implementation sequencing

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

Unblocks or integrates with: #75.

Technical dependency note: Backed claims are separate from fungible LP shares and concentrated positions; claims require their own actual reserve and issuance authority.

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