[DeFi][FIN-26] Scoped signed intents, delegation, nonces and replay protection #76

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

Plain-language explanation

Users should be able to authorise a narrowly defined operation without giving the router unlimited spending rights. If a transaction is rebuilt after stale state, the new bytes must still satisfy the original signed intent.

Mermaid walkthrough

flowchart TD
A["User signs restricted intent"] --> B["Bind signer, nonce, pool, asset and limits"]
B --> C["Builder creates transaction"]
C --> D{"On-chain authorisation still holds?"}
D -- No --> X["Reject"]
D -- Yes --> E["Execute once under scoped authority"]

Implementation layer: On-chain authorisation protocol + wallet adapter.

Dependencies / staging: Closed #25 cryptographic domain authority, #61 FIN-11 pool/network context, FIN-22 for any claimed time expiry.

Detailed design and security review

A signature must authorise exactly what will execute

A normal transaction signature authorises specific serialized bytes. A higher-level signed trading intent can allow a builder to reconstruct candidate transactions after pool state changes, but only if the on-chain authorisation path actually verifies that same intent against the new transaction. The SDK must not treat a signature over an old transaction as automatically authorising replacement bytes.

Intent schema and replay domain

Freeze a canonical signed-intent schema containing chain/genesis, protocol/action version, full asset/PoolId/position/claim identities, signer and optional delegate, authorised spender/recipient, max input, min output, capacity/fee ceilings, nonce, cancellation/revocation domain, supported action scope and temporal restrictions. Every optional field must have explicit semantics; default omission cannot silently become unlimited permission.

Implement standard CKB Lock transaction signing and any separately admitted intent-verification profile through existing cryptographic/authority tools. State who stores nonce/revocation state, how it is spent/updated and why concurrent cancellation versus execution cannot both succeed. Delegation must be scoped by spend amount and exact operation; a copied owner field is not a valid proof.

Implementation sequence

1. Freeze shared canonical vectors, domain-separated signatures and exact subject message construction.
2. Implement one delegated pool swap and one owner-position operation with authentic Lock signature, intent checking and nonce transition.
3. Build a stale-quote retry that reconstructs the final transaction and revalidates against the original authorised maximum-spend/minimum-receive bounds; obtain new transaction signing where required.
4. Add revocation/nonce replacement and limited batch-authorisation with controlled replay windows.
5. Integrate time-scoped intent only after [DeFi][FIN-22] Chain-authenticated time, freshness and expiry feasibility #72 establishes an admissible source or an explicitly labelled external trust profile.

Adversarial evidence

Evidence

Complete-transaction signing vectors must match generated ABI, standard Locks and independent verification. Report exact message bytes/hashes, nonce lineage, transaction-byte changes, signer/delegate permissions and resource limits.

End-to-end security flow

flowchart TD
    A["User approves bounded operation intent"] --> S["Canonical domain-separated signature"]
    S --> B["Builder creates current transaction"]
    B --> V["Script checks intent, nonce and full transaction binding"]
    V --> C{"Signer, limits and replay state valid?"}
    C -- No --> X["Reject"]
    C -- Yes --> E["Execute authorised operation exactly once"]

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

• Define signed intent domain including chain/genesis, permitted operation(s), signer/delegate/spender, asset/pool/hook identity, nonce, recipient, amounts, slippage/fees and cancellation rules.
• Use existing CKB signature/Lock integration where sufficient; separate exactly signed transaction bytes from intent-level authorization of reconstructed candidate transactions.
• Specify replay, nonce uniqueness, revocation, permission update/expiry (only when FIN-22 supports it), cross-network and batch delegation.
• Do not invent a parallel wallet/signing framework; integrate with existing generated builder/CKB adapter.

Acceptance criteria

• Authorised delegated swap/claim/position operations succeed once and reject replay across same or different chain/pool, recipient or spender.
• Changed max input, min output, fees, recipient, pool, signer/delegate or nonce rejects, including stale-state rebuilding.
• Cancellation/nonce races and batch authorization limits have on-chain executable outcomes.
• Wallet signature and preflight/CKB-VM/transaction bytes match a documented user-intent contract.

Security / scope boundary: Client TTL is not chain-enforced expiry; unrestricted ambient allowances are not an acceptance shortcut.

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: #25, #61.

Optional profile integrations: #72.

Unblocks / consumed by: #74, #75.

Reason for this sequence: An ordinary signed CKB transaction and a signed portable operation intent are different credentials; rebuilding changed bytes requires freshly valid authorisation.

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