What reviewers are being asked to assess

Status: design proposal. No architecture has been selected, implemented, or assigned a release date. This issue introduces CellScript to reviewers who may not know it and allows the maintainer to invite Hanssen, Retric, Guopeng, and others. Naming them does not imply that they have been invited, agreed, or completed a review.

The decision is which layers of CellScript cross-contract interoperability should reuse SSRI, which should reuse ckb-script-ipc, and which constraints CellScript must own. Review capabilities and trust boundaries before APIs. “IPC” can mean either CKB's process-communication syscalls or XuJiandong's library; do not conflate them.

In one sentence: how a wallet discovers a contract, how a contract admits a counterpart, and how processes exchange arguments and results at runtime are three related but distinct problems. Claims that “IPC is more advanced” need concrete evidence of interoperability, cost, maintenance, and security benefits.

1. CellScript in ten minutes

CellScript compiles .cell source into CKB-VM RISC-V ELF and emits typed interface and execution-boundary descriptions. An independent artefact checker verifies bounded structural contracts between the ELF and those descriptions; it does not establish arbitrary business-logic correctness. CKB still consumes existing Cells and creates new Cells, with each Lock/Type Script validating the same transaction.

Foundational issues #9/#10/#11/#28/#29/#80 were closed (checked 18 October 2026). The code baseline is 602795b3, a bounded accepted state on the 0.32 development branch, not a new stable release or claim of public deployment.

Starting points: end-to-end tutorial, open-handle contract, and instance contract and real example.

2. One example, three distinct needs

Suppose an institution issues document credentials. Alice wants to revoke one credential and unlock an observer Lock that references it, in the same transaction.

1. The wallet needs to discover the credential type, available methods, and how to construct a transaction: discovery and off-chain construction.
2. The observer Lock must establish that the actual input credential comes from an approved implementation, belongs to the right namespace, has a permitted category, and matches the instance selected for this operation: identity and authorisation.
3. The credential Type must actually validate the issuance/revocation rules, and the issuer Lock must check the signature: complete transaction execution.
4. Only if the application additionally needs an independent algorithmic verifier must a parent Script launch it, transmit data, read its result, and handle failures: process communication. The first three steps do not themselves require general-purpose IPC.

---
config:
  flowchart:
    subGraphTitleMargin:
      top: 10
      bottom: 20
---
flowchart TB
  subgraph Tool["Off-chain · Discovery and construction"]
    D["SSRI / other discovery entry"] --> B["Construct candidate transaction"]
    B --> P["ProtocolBundle · Check identity and roles"]
  end
  subgraph Chain["On-chain · Same transaction"]
    P --> L["Issuer Lock · Check signature"]
    P --> T["Credential Type · Validate revocation"]
    P --> O["Observer Lock · Instance policy"]
    O -. "Only if extra computation is required" .-> C["Parent process ⇄ Child verifier"]
    L --> A["All required groups pass"]
    T --> A
    O --> A
  end
  classDef tools fill:#e8f1ff,stroke:#4267a8,color:#132e53;
  classDef checks fill:#e5f6ee,stroke:#27835d,color:#133d2e;
  classDef optional fill:#fff3d9,stroke:#aa791c,color:#513a12;
  class D,B,P tools;
  class L,T,O,A checks;
  class C optional;

3. Research evidence: distinguish concepts, implementations, and unknowns

Verified on 18 October 2026. DeepWiki was used only for navigation; conclusions here rely on original proposals and pinned source.

• Hanssen's original SSRI proposal: Script-Sourced Rich Information, method paths, off-chain execution contexts, and information/logic provided by Scripts.
• ckb-ssri-std @ 93f3a779: its README still lists TODOs such as a unified entry and attribute macros; ssri_methods! already provides discovery/dispatch. Conceptual soundness does not imply that every proposed feature is implemented.
• ckb-script-ipc @ 4044faee: procedural macros generate client/server code; runtime provides spawn/pipe, framing, and native execution. It is not exclusively on-chain.
• RFC 0050: underlying spawn/wait/read/write/pipe semantics. Experiments must additionally pin node/VM/ckb-std versions, rather than relying solely on a moving RFC.

These are source observations, not a security audit or performance ranking. Default JSON does not mean IPC framing can only carry JSON. Replacing it with Molecule requires an explicit negotiated interoperable profile or an honestly named new protocol incompatible with the default upstream client.

4. Compare four routes fairly

A small independent protocol remains a possible implementation variant of A/C/D, but requires precise justification for not reusing upstream contracts, disclosure of shared wire semantics, and a long-term maintainer. “More secure” or “more advanced” alone is inadequate. The current preference is to experiment by layer, not to commit to D or any new dependency.

5. Comparable experiments and decision process

1. Pin problems and samples: credential discovery/construction, one fixed-size pure verifier call, and two ordered calls. All routes use the same code identity, requests, context, expected success/failure. Do not compare an unauthenticated demo against fully checked CellScript.
2. Freeze interface semantics: target identity, full signature/codec hash, method number, read permissions, effects, input/output bounds, and error classes. Short-ID collisions must fail or have verifiable disambiguation; method number alone is not interface identity.
3. Native Rust baseline: implement equivalent checks with a pinned ckb-std; measure application-specific code, reusable libraries, SDK construction, and testing. Compare complete implementations, not one DSL helper against all transitive Rust dependencies.
4. Disposable adapters: test SSRI, default upstream IPC, candidate bounded IPC, and existing fixed path. Mark unimplemented cases as missing, not zero-cost. Pseudocode must not be presented as a working API.
5. Reproducible evidence: record exact source/lock/compiler/ELF/network/VM versions, raw transactions/witnesses, code and transport sizes, memory, single/repeated call cycles, maximum-success and latest-failure cases. Report off-chain cold/warm latency separately. Mark unobservable memory as unavailable.
6. Architecture decision record (ADR): document decisions to adopt, reject, or defer, with reasons and reconsideration triggers. Address external review disagreements individually; the maintainer assigns ownership and implementation scope before development.

Authoring direction — 2026-10-19

The authoring requirements adopted in #47/#48/#49 also apply to this decision. Treat application-facing declarations and transport bindings as separate design decisions: choosing SSRI, IPC, both, or neither must not automatically freeze the upstream library's plumbing as CellScript syntax. Any shared interface description must preserve the different context, authority, error, and lifecycle contracts; a pleasant call expression is not evidence that these contracts are interchangeable.

Compare all four routes using complete author-written examples: credential discovery and candidate construction, one checked verifier request, and two ordered requests. Show the declarations, reusable helpers, caller, generated client/builder, and rejection paths. Evaluate named business roles and methods, structurally resolved typed fields and policies, and named resource limits declared once at the relevant interface or scope. Avoid repeated positional budgets, numeric role ordinals, duplicate type/role declarations, and hand-written transport details at ordinary use sites. A declaration must still resolve to exact checked identities, codec bounds, and execution obligations.

Use the same borrowing direction as #47–#49: ordinary direct reads should stay direct; an explicit borrow scope should express a real retained-view lifetime. Bounded non-escaping helper composition is a target for review, not an already implemented capability. Local read-only views, owned collections, off-chain query results, and child-process messages retain different authority and lifetime rules. Borrowed pointers are not a cross-process wire format, and a decoded response does not acquire authority over foreign Cells.

Authoring review is part of architecture acceptance before a stable API is frozen. Record which repetition the compiler or generated adapters remove, which limits and failure decisions the author must still state, and which helper shapes remain unsupported. Compare equivalent reusable Rust libraries fairly. Preserve exact/open/instance admission, complete Script-group validation, numeric resource evidence, and independent checking; concise syntax cannot waive any of them. Exact grammar and protocol selection remain undecided.

6. Actual dependencies on #47/#48/#49

• [0.33][Runtime] Extend bounded Cell selection and correspondence for heterogeneous and dynamic data #49 covers bounded selection, completeness, and input/output correspondence for heterogeneous role-based Cell collections; priority 1. Fixed-layout work can proceed separately. Cross-contract observation must not turn into ownership of foreign resources.
• [0.33][ABI] Support bounded nested dynamic values with canonical codecs #48 covers canonical codecs for nested variable-length values; priority 2. Bounded read-only decoding need not require heap allocation. Variable-length payload support in [0.33][Runtime] Extend bounded Cell selection and correspondence for heterogeneous and dynamic data #49 depends on its specific codec.
• [0.33][Runtime] Add bounded allocation-backed value collections and deterministic Map/Set #47 covers bounded per-invocation allocation and deterministic Map/Set; priority 3. It becomes a dependency only when owned dynamic values or general-purpose collections are selected.
• Fixed-request/fixed-result IPC tests and limited off-chain discovery should not be blocked by all three issues collectively. Conversely, integrating SSRI/IPC does not complete them.
• Hooks, economic deltas, and routing remain under [DeFi][FIN-19] Authenticated before/after operation hooks and permissions #69/[DeFi][FIN-21] Permissioned extension balance deltas and alternative pricing curves #71/[DeFi][FIN-25] Bounded command-plan routing and authenticated liquidity migration #75; successful communication proves neither asset conservation nor authorisation nor correct quotations.

7. Deliverables, review, and closure criteria

This issue owns architecture selection. Two companion issues cover SSRI integration and bounded IPC ABI/lifecycle design; see Design workstreams.

• Review complete authoring examples for all four routes against the [0.33][Runtime] Add bounded allocation-backed value collections and deterministic Map/Set #47/[0.33][ABI] Support bounded nested dynamic values with canonical codecs #48/[0.33][Runtime] Extend bounded Cell selection and correspondence for heterogeneous and dynamic data #49 direction: named roles/methods and limits, typed fields/policies, helper composition, and visible authority/lifecycle boundaries. Record remaining gaps before stable API freeze.
• Pin all three upstream source revisions and document discrepancies between SSRI concepts, inspected implementation, and server versions.
• Compare all four routes on equivalent scenarios; mark unexecuted measurements as absent, never pretend they are performance results.
• Complete the responsibility matrix for identity, instance, context, permissions, codec, lifecycle, resources, and errors.
• Supply comparable Rust and CellScript examples, clearly separating executable code, proposed APIs, and pseudocode.
• Give both companion designs executable implementation slices, threat cases, methods for freezing numeric budgets, and acceptance owners.
• Record actual invited reviewers' feedback and maintainer decisions. Silence is not endorsement; review waivers for earlier issues do not automatically carry over.
• Record written accept/reject/defer decisions and reopening conditions. Closing the design issue is not equivalent to implementation or deployment.

Questions for reviewers: Have we defined SSRI's scope too narrowly? Does the IPC library's actual evolution change these observations? Which existing external consumers are mandatory interoperability targets? Can we share interface descriptions while retaining distinct transports? Which state or permission decisions must never depend on a service return value? Is maintaining two protocols worthwhile for v1? Please provide concrete calls and failure cases.

Design workstreams

• Overall selection and decision record: [Design][Interop] SSRI / IPC architecture decision: discovery, contract admission, and runtime communication #81.
• SSRI entry, context, and candidate transactions: [Design][SSRI] Script self-description, contextual queries, and transaction construction for wallets and SDKs #82.
• Bounded IPC ABI, lifecycle, and interoperability: [Design][IPC] Bounded parameterised verification services: typed requests and responses, child lifecycle, and upstream interoperability #83.

All three are open designs. Small experiments in #82/#83 may run in parallel to produce evidence; #81 owns the final architecture decision. These are references, not claims that GitHub blocking dependencies have been configured.

Further reading

ProtocolBundle end-to-end tutorial.