You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Define and implement one versioned, typed, bounded contract for the CKB transaction data and runtime adapters that production CellScript verifiers may use. This closes the current gap between individually implemented source/byte helpers and a release-level support matrix suitable for the 0.30 business portfolio.
This issue does not add a raw numeric-syscall escape hatch. Each admitted operation must have a typed source, deterministic memory bound, stable failure behavior, metadata and ProofPlan records, lowering, and positive/adversarial CKB-VM evidence.
Current boundary
The 0.26b baseline already exposes useful typed transaction views, exact byte/span reads, transaction preimages, hashes, and bounded EXEC or SPAWN/WAIT adapters. Issue #12 owns temporal and Since domains. Those pieces do not yet share one complete matrix proving which Cell, input, header, witness, Script, hash, source, and syscall-result families are supported together in ordinary, persistent-policy, builder, and independent-checker paths.
Required contract
The 0.30 matrix must decide and test:
current Script and Script hash;
Cell data, capacity, occupied capacity, Lock and Type Scripts and hashes;
input out points and since;
headers, header dependencies, epochs, timestamps, and block numbers;
raw witnesses and WitnessArgs fields with explicit ownership and bounds;
transaction, Script-group, input, output, CellDep, and header-dependency sources;
indexes, lengths, partial reads, and out-of-bound behavior;
transaction preimages and exact authorization message domains;
CellDep lookup and exact-identity EXEC or SPAWN/WAIT adapters; and
stable errors for syscall failure, malformed Molecule values, invalid sources, invalid indexes, and oversized byte ranges.
Every supported API must identify its source kind, value type, maximum read size, allocation/stack behavior, failure code, evidence tier, and supported entry contexts. Unsupported combinations must fail before production artifact emission.
Implementation phases
Phase 0 — matrix and identities
inventory the existing source, witness, header, hash, Script, byte, EXEC, SPAWN, WAIT, and IPC APIs;
classify each as implemented, metadata-only, fail-closed, or outside 0.30;
define source and value types without changing Edition 2026 meanings;
assign a versioned runtime-view contract and stable error taxonomy; and
expose admitted values and conversions through the authoring grammar and type checker;
retain source, index, field, byte range, and message-domain provenance in structured IR;
reject confused source kinds, unchecked narrowing, ambiguous witnesses, and unbounded materialization; and
update formatter, recovering parser, LSP, VS Code, metadata, constraints, ProofPlan, and source maps together.
Phase 2 — runtime lowering
lower every admitted operation through canonical CKB syscalls and Source encodings;
enforce bounds before pointer arithmetic or allocation;
preserve exact syscall statuses and terminal verification failures;
support the same admitted contract in ordinary/scoped and persistent-policy entries; and
keep all unclassified syscalls fail-closed.
Phase 3 — independent and executable evidence
bind claimed runtime-view operations to machine blocks in the standalone checker;
add mutations for source, index, length, field, hash, status, and omitted bounds checks;
run identical fixtures through simulator where applicable and CKB-VM where authoritative;
add builder and adapter codec parity tests; and
measure cycles, stack, code size, witness bytes, and transaction size at maximum admitted bounds.
Acceptance matrix
At minimum, cover valid and invalid reads for every admitted source, zero-length and maximum-length byte ranges, indexes 0/nonzero/last/one-past-last/large-u64, missing and malformed witnesses, absent Type Scripts, wrong Script groups, header-dependency presence and absence, since type mismatches, partial syscall reads, wrong CellDep identities, and nonzero child status.
The same operation used from ordinary and persistent-policy paths must either produce the same typed/runtime contract or reject with a documented entry-context error. No metadata-only record may be counted as executable support.
Completion criteria
A reviewed support matrix classifies every current CKB-facing API.
All admitted APIs have typed source/value contracts and deterministic bounds.
Edition 2026 compatibility and the new 0.30 source identity are explicit.
Formatter, LSP, VS Code, metadata, constraints, ProofPlan, and builders agree.
CKB-VM positive and adversarial cases cover every admitted row.
Standalone-checker mutations cover every machine property it claims.
Worst-case resource measurements are recorded and gated.
dev, ci, and backend gates pass.
Independent review of source decoding, bounds, witness ownership, and syscall failure handling is complete.
Non-goals
raw syscall numbers or inline assembly;
unbounded transaction-wide reads or allocator-backed unbounded values;
silently treating syscall errors as data;
changing stable Edition 2026 behavior without migration; or
claiming external verifier internals from successful delegation.
Summary
Define and implement one versioned, typed, bounded contract for the CKB transaction data and runtime adapters that production CellScript verifiers may use. This closes the current gap between individually implemented source/byte helpers and a release-level support matrix suitable for the 0.30 business portfolio.
This issue does not add a raw numeric-syscall escape hatch. Each admitted operation must have a typed source, deterministic memory bound, stable failure behavior, metadata and ProofPlan records, lowering, and positive/adversarial CKB-VM evidence.
Current boundary
The 0.26b baseline already exposes useful typed transaction views, exact byte/span reads, transaction preimages, hashes, and bounded EXEC or SPAWN/WAIT adapters. Issue #12 owns temporal and
Sincedomains. Those pieces do not yet share one complete matrix proving which Cell, input, header, witness, Script, hash, source, and syscall-result families are supported together in ordinary, persistent-policy, builder, and independent-checker paths.Required contract
The 0.30 matrix must decide and test:
since;WitnessArgsfields with explicit ownership and bounds;Every supported API must identify its source kind, value type, maximum read size, allocation/stack behavior, failure code, evidence tier, and supported entry contexts. Unsupported combinations must fail before production artifact emission.
Implementation phases
Phase 0 — matrix and identities
Phase 1 — typed frontend and IR
Phase 2 — runtime lowering
Phase 3 — independent and executable evidence
Acceptance matrix
At minimum, cover valid and invalid reads for every admitted source, zero-length and maximum-length byte ranges, indexes 0/nonzero/last/one-past-last/large-u64, missing and malformed witnesses, absent Type Scripts, wrong Script groups, header-dependency presence and absence,
sincetype mismatches, partial syscall reads, wrong CellDep identities, and nonzero child status.The same operation used from ordinary and persistent-policy paths must either produce the same typed/runtime contract or reject with a documented entry-context error. No metadata-only record may be counted as executable support.
Completion criteria
dev,ci, andbackendgates pass.Non-goals
Dependencies
Sincevalues;