Skip to main content

Open questions

Neutron's documentation convention is to list gaps instead of filling them with guesses. This page collects the significant ones.

Release gates​

Several development surfaces still require release evidence.

Certified Assets qualification​

Certified Assets API 2 now returns direct certified responses and does not use the static-asset streaming callback. The repository has a source-owned local release runner covering certificate/witness verification, raw and PocketIC gateway observations, hostile Range handling, upgrade persistence, browser CORS, quotas, and cross-scope isolation.

The candidate binding is only an input inventory, not evidence. Qualification requires a pass receipt that validates against the exact current candidate, compiler, assembler, runner, and sources. The checked-in tree currently has the candidate binding but no qualification receipt.

Even a valid receipt is bounded local regression evidence: it does not establish cycle cost, proof size, allocator behaviour, or upgrade safety at the 100,000-entry production ceiling, nor does it replace deployed-mainnet gateway qualification.

Chain-key signing scope​

V1 is assertion-only. It cannot encode or sign a raw chain transaction, and its install grant is not Neutron's one-shot value-moving consent.

An external verifier may still treat a signed assertion as high-impact authority, so apps must constrain assertion semantics themselves. Any future typed transaction adapter needs its own transaction-shaped, one-shot owner confirmation immediately before signing.

Release evidence still requires real local ECDSA plus production public-key/signature verification and observed cycle-spend validation; the deterministic assertion tests do not substitute for those environments.

Package authenticity​

Canister or DAO signatures for packages are not implemented. The install flow does not verify package authenticity.

What certification and digests prove is byte provenance and integrity — not publisher identity, legality, security review, or quality.

Open: what signature format and trust root should decide whether an app is authentic?

Ownership and recovery​

  • The kernel stores a flat principal set and does not encode the single human owner separately from installer and technical authorities, or attach labels.
  • The hosted flow now uses a one-time activation code. A valid code authorizes the actual Internet Identity caller atomically, and the dispenser retires both its kernel authorization and IC controller authority.
  • A verified IC controller can explicitly recover kernel authorization, but there is no ownership-transfer flow or automatic credential backup.
  • Losing the browser-held provisioning key or activation code before activation has no server-side human recovery path. The code remains a bearer until used.
  • The dispenser has no registry-removal, canister-delete, or ownership-transfer API and cannot repair a completed instance after retiring its authority.

Open: should the provisioning secrets have an encrypted/exportable backup, and what recovery should exist for a user who loses every authorized identity and has no external recovery controller?

Dispenser operations​

  • The CMC request leaves subnet_type null and selects one immutable target subnet configured when the dispenser is installed. There is no per-user selection, fallback, or multi-subnet routing policy.
  • Starter-payload maintenance now checks the caller against the dispenser's live IC controller list, and both frontend and backend enforce a 2 ICP minimum.
  • Non-retriable CMC refunds or invalid transactions still need operator/user handling, and the starter uploader does not cross-check the live update source.
  • A paid mainnet deposit-through-activation run, including final controller retirement and ambiguous-reply recovery, remains release evidence.

Browser boundary​

  • Persisted cross-app grant policy and browser resource quotas remain open — grants are currently one-call or session only.
  • A raw, no-dialog arbitrary canister call action is not exposed to app iframes. The validated callCanisterDialog() path exists and obtains approval for each call; any future raw path would need its own app policy and allowlist design.

The resident-background launcher checks the iframe and Window credentialless state required by the compiled background mode and fails closed on a mismatch; tiles and trays set the required attributes but do not perform that preflight. Open: what global unsupported-browser gating is needed for tiles and trays, which browser feature versions must be qualified, and what CPU, memory, network-byte, storage, and GPU limits should apply to resident frames?

Open: should generic external canister calls made with the owner's browser identity remain governed only by per-call approval, or also by manifest permissions, canister allowlists, and persisted user policy? Exact preapproved self calls and persistent backend-call reservations already have separate manifest-bound policies.

The generic capability diff shown for an update deliberately does not classify a changed capability as broader or narrower. That classification needs capability-specific policy.

Compiler and assembly​

  • Migration work is bounded to synchronous Motoko functions; large online data transformations need app-specific compatible schemas instead.
  • JSON Schema is supplemented by semantic validation for cross-field, content-addressing, dependency, capability, and safe-path constraints.

Packaging​

  • The packer includes every regular file under dist/; active ignore-file handling is still disabled. Package preparation separately enforces the manifest, entry module, hash, path, size, and semantic constraints.

Developer experience​

  • No published app-template generator. Hello and Kitchen Sink are the current minimal and feature-rich starting points.

Resource governance​

  • Scheduled tasks let untrusted app code execute with no open tile and spend instructions on every interval. Neutron does not claim a general CPU quota beyond IC execution limits and the scheduler's frequency and overlap bounds.
  • There is no V1 instruction budget below the IC update-message limit for an admitted public HTTP handler.
  • App usage telemetry is deliberately low-side and not billing-grade: it omits variable byte fees, response-callback bases, shared global-timer dispatch, storage, and compute allocation.