This follows our October 5 article on the new ckSOL deposit pipeline. Since then, the team has described the full user flow in one place and renamed the withdrawal and status endpoints. It also said it is "now about to launch the production version".

What changed in ckSOL

ckSOL is a chain-key token that represents SOL on the Internet Computer. According to the thread, a canister smart contract holds all SOL that backs ckSOL using "threshold Schnorr over Ed25519". The matching private key is never derived. The token follows the "ICRC-1, ICRC-2, and ICRC-3" standards.

The system has two parts:

• ckSOL Ledger: a standard ICRC ledger canister.
• ckSOL Minter: converts between SOL and ckSOL and holds all backing SOL. It reaches Solana through the SOL RPC canister. That canister sends each query to several independent JSON-RPC providers and only accepts an answer they agree on.

The thread says the design "closely follows ckETH". Two design points matter most for integrators:

1. The minter credits deposits from address balances, not from single transfers. Each ICP account (principal plus subaccount) gets its own Solana deposit address. After sending SOL, the user calls deposit_sol. The minter moves the full balance of that address into its main account (a sweep). When the sweep is finalized, it mints ckSOL for the amount the sweep actually moved. You don't need a Solana transaction signature, so deposits from centralized exchanges work. If several transfers are each too small on their own, the minter credits them together once their total is large enough. Automatic deposit discovery, where the user does not call anything, will come in a later upgrade after launch.
2. Withdrawals never expire. The user gives the minter an ICRC-2 approval and calls withdraw_sol with a destination address and amount. The minter burns the ckSOL and sends the same amount of SOL, minus a withdrawal fee. Withdrawals are sent as "durable-nonce transactions". With a durable nonce, the minter can check on-chain whether a transaction landed. It does not have to guess from a missing status in an RPC provider's response.

PR #262 in dfinity/cksol is titled "refactor(minter)!: name the withdrawal and status endpoints after the asset". It merged on October 8. The ! in the title marks a breaking change. The PR renames:

deposit_sol already had this name and did not change. The PR renames the other Candid types the same way: WithdrawalOk, WithdrawalError and WithdrawalStatus become WithdrawSolOk, WithdrawSolError and WithdrawSolStatus.

Who is affected

• Wallet and dapp developers who wrote against older staging builds. Calls to withdraw, deposit_status or withdrawal_status will fail against a minter built after PR #262.
• Teams that used a transaction signature for deposits. Earlier README examples showed a process_deposit call that took a Solana signature. The flow in the thread uses deposit_sol and reads the balance of the deposit address instead. Check the current Candid file before you port old code.
• Exchanges and custodians. Each account has its own deposit address, so no memo field is needed. The team gives this as the reason for the design.

The repository README lists these canister IDs:

On October 9, NNS proposals 144313 and 144314 upgraded lh22c-kyaaa-aaaar-qb5nq-cai and ls5lp-lqaaa-aaaar-qb5oa-cai to new wasm hashes. The forum post still says production is about to launch. Treat mainnet ckSOL as closed to users until the team announces the launch.

In the same thread, a community member asked whether ckSOL could be removed if few people use it. The NNS has already agreed to wind down ckDOGE for that reason. The original poster replied with a link explaining why the team expects ckSOL to be useful, and the community member said this answered the concern. The thread contains no usage commitment or policy.

What to do now

1. Search your code for calls to withdraw, deposit_status and withdrawal_status on the ckSOL minter. Rename them to withdraw_sol, deposit_sol_status and withdraw_sol_status.
2. Regenerate your Candid bindings from the minter interface in dfinity/cksol so that type names such as WithdrawSolArgs match.
3. If you have a deposit flow based on transaction signatures, replace it with these steps: get the deposit address, send SOL, call deposit_sol, then poll deposit_sol_status.
4. For withdrawals, call icrc2_approve on the ckSOL ledger to approve the minter before you call withdraw_sol.
5. Test on ckDevnetSOL first. The repository README uses icp-cli, with -e staging or -e prod to choose the environment. The two read calls below come from the README. PR #262 did not rename these endpoints:

# Fees, minimum amounts and minter balance
icp canister call -e staging cksol_minter get_minter_info '()'

# Your Solana deposit address (owner = null uses your calling principal)
icp canister call -e staging cksol_minter get_deposit_address \
  '(record { owner = null; subaccount = null })' --query

6. Read fees and minimum amounts from get_minter_info instead of hardcoding them. The thread says the design document explains the fee model and parameter choices.

Caveats

The team has announced the production deployment, but it is not live yet. PR #262 is a breaking API change. A review comment on that PR pointed out that a README withdrawal example still used the old withdraw name, so trust the Candid file over older docs. Automatic deposit detection is not part of the first release.

What Motoko is for

Motoko is the language DFINITY designed for Internet Computer canisters. The official overview describes it as "designed for AI agents building backends for apps and services on the Internet Computer". People write it by hand too. It compiles straight to WebAssembly, handles Candid serialization for you, and models each canister as an actor. The Hello, world page puts it this way: "In Motoko, an actor is an object capable of maintaining state and communicating with other entities via message passing."

Three features matter for a first canister:

• Query and update methods. Update methods can change state. In the docs' words, "Query methods are read-only and return information from the canister without changing its state."
• Orthogonal persistence. Actor variables survive upgrades without serialization code or upgrade hooks.
• Strong types. Variants, options and generics catch mistakes at compile time, such as using the wrong integer type as an index.

If you already have Motoko code from before 2.0 and need to upgrade it, skip this tutorial and follow our step-by-step Motoko 2.0.0 migration guide or the official moc v2 migration document.

Prerequisites and pinned versions

You need Node with npm to install the tools, and a Linux or macOS shell. The steps below apply to these versions:

The official Motoko overview page shows a mops example that pins an older compiler. For this guide, pin 2.0.0 as shown in step 2.

If you don't want to install anything yet, ICP Ninja runs Motoko projects in the browser. You can paste the actor from step 3 into it. The rest of this guide uses the local toolchain.

The steps at a glance:

1. Install icp-cli, ic-wasm and mops, then check their versions.
2. Write the project config and the mops manifest, then install packages.
3. Write the actor and type-check it with moc.
4. See the Nat64 indexing error so you recognise it later.
5. Build the canister with icp.
6. Start a local network, deploy, and call the methods.

Step 1: Install the tools and check versions

The first command installs icp-cli and ic-wasm from the icp-sdk npm scope, then installs mops. This step is marked Not run on the page because installing global tools needs network access. Run it on your own machine or in your CI image with internet access.

npm install -g @icp-sdk/icp-cli @icp-sdk/ic-wasm && npm install -g ic-mops

Next, confirm that the versions match the table above. The command prints the version of the CLI, the compiler and the package manager.

icp --version && moc --version && mops --version

icp 1.6.0
Motoko compiler 2.0.0 (source qyfd59bi-20ns70k0-wsgga437-asc33x9r)
CLI 3.4.2
API 1.3

The output shows "icp 1.6.0" and "Motoko compiler 2.0.0". The mops lines show CLI 3.4.2 and API 1.3. If your moc is older, the M0217 warning in step 3 will not appear, and code written for 2.0 may behave differently on upgrades.

Step 2: Write the project files

icp-cli reads the project config file at the project root. This one declares a single canister named backend. It is built with the Motoko recipe at version v4.0.0, uses src/main.mo as its entry point and takes no install arguments.

canisters:
  - name: backend
    recipe:
      type: "@dfinity/motoko@v4.0.0"
      configuration:
        main: src/main.mo
        args: ""

The mops manifest pins the compiler and the standard library. The toolchain section pins moc to 2.0.0, so every machine that builds the project uses the same compiler. The dependencies section pulls in core 2.6.2, the standard library that replaces the older base package.

[toolchain]
moc = "2.0.0"

[dependencies]
core = "2.6.2"

Now install the packages. This step is also marked Not run on the page because downloading the core package needs network access. On your machine it fetches core and the pinned compiler.

mops install

To see what mops resolved, list the package sources and the path of the pinned compiler:

mops sources && mops toolchain bin moc

--package core .mops/core@2.6.2/src
~/.cache/mops/moc/2.0.0/moc

The first line, "--package core .mops/core@2.6.2/src", is the flag mops passes to moc so that imports starting with mo:core resolve to version 2.6.2. The second line shows the pinned compiler at ~/.cache/mops/moc/2.0.0/moc. The Motoko recipe in the project config uses these sources during the build.

Step 3: Write the actor

This actor shows the four things the forum asks about most: query and update methods, a typed error, persistent and transient state, and caller information.

persistent actor Counter {
  type Result = {
    #ok : Nat;
    #err : Text;
  };

  var count : Nat = 0;
  transient var lastAmount : Nat = 0;

  public query func getCount() : async Nat {
    count
  };

  public query func getLastAmount() : async Nat {
    lastAmount
  };

  public func add(amount : Nat) : async Result {
    if (amount == 0) {
      return #err("amount must be positive");
    };
    count += amount;
    lastAmount := amount;
    #ok(count)
  };

  public shared query(msg) func whoAmI() : async Principal {
    msg.caller
  };
};

What each part does:

• Result is a variant type with #ok carrying a Nat and #err carrying Text. Returning it lets callers handle a bad input without the call failing. The core library also has a generic Result module you can use instead of writing your own.
• count is a normal actor variable. In moc 2.0.0 it survives upgrades without any extra keyword.
• lastAmount is marked transient. A transient variable is reset to its initial value, here 0, on every upgrade. Use it for caches and other data you can rebuild.
• getCount and getLastAmount are query methods. They are fast and read-only.
• add is an update method. It rejects 0 with an #err before touching state, and otherwise updates both variables.
• whoAmI is declared with shared query and a message argument. The message gives you msg.caller, the Principal of whoever made the call. This is how you get caller information. To check access, compare it against a principal you stored. Use Principal.isAnonymous from core to reject callers that are not signed in.

Type-check the file without building:

moc --check src/main.mo

src/main.mo:1.1-1.11: warning [M0217], redundant `persistent` keyword

The check passes, but moc prints warning M0217: "redundant persistent keyword". In moc 2.0.0 every actor is persistent by default, so the keyword on line 1 no longer does anything. You can delete it or keep it. The file compiles either way, and the warning only reminds you of the new default.

Step 4: The Nat64 indexing pitfall

A common forum question is why an array lookup fails when the index comes from a timestamp, a Candid field or a counter typed as Nat64. This file reproduces it:

actor {
  let values : [Nat] = [10, 20, 30];
  let index : Nat64 = 1;
  let selected : Nat = values[index];
};

The check fails on purpose:

moc --check src/nat64-pitfall.mo

src/nat64-pitfall.mo:4.31-4.36: type error [M0096], expression of type
  Nat64
cannot produce expected type
  Nat

Error M0096 points to line 4, columns 31 to 36, which is the index expression. It says an expression of type Nat64 "cannot produce expected type" Nat. Motoko arrays are always indexed with Nat, its arbitrary-precision natural number type, and the compiler never converts between number types for you. To fix it, import the Nat64 module from core and convert the value with Nat64.toNat before using it as an index. A simpler option is to keep indexes typed as Nat from the start. Use Nat64 only where the interface needs a fixed width, for example in a Candid nat64 field.

Step 5: Build the canister

With the working actor in place, build it through icp-cli. The build compiles src/main.mo with the pinned moc and post-processes the module.

icp build

Building canisters:
Canisters built successfully

The output ends with "Canisters built successfully". The pitfall file is not part of the build because the project config names only src/main.mo as the entry point.

Step 6: Deploy and call the canister

This step starts a local network in the background, deploys the canister and calls it four times. The calls work as a smoke test: two good inputs, one bad input, and a read.

icp network start -d && icp deploy && icp canister call backend add '(2 : nat)' && icp canister call backend add '(0 : nat)' && icp canister call backend add '(3 : nat)' && icp canister call backend getCount '()'

For background mode, network output will be redirected:
  stdout: ~/motoko-first-canister/.icp/cache/networks/local/network-launcher/stdout.log
  stderr: ~/motoko-first-canister/.icp/cache/networks/local/network-launcher/stderr.log
Network started on port 8000
Seeding ICP and cycles account balances
To stop the network, run `icp network stop`
Building canisters:
Creating canisters:
Setting environment variables:
Applying canister settings:
Checking compatibility:
Installing canisters:
No canisters have sync steps configured
Created canister backend with ID 4caro-hl777-77775-aaaba-cai
Deployed canisters:

Backends (Candid UI):
  backend: http://4mc4g-43777-77775-aaaaa-cai.localhost:8000/?id=4caro-hl777-77775-aaaba-cai
(variant { ok = 2 : nat })
(variant { err = "amount must be positive" })
(variant { ok = 5 : nat })
(5 : nat)

The output shows the following:

• The local network started on port 8000, and the launcher writes its logs to files under the project's .icp cache folder.
• The deploy created the backend canister with ID 4caro-hl777-77775-aaaba-cai and printed a Candid UI link for it.
• Adding 2 returned the ok variant with 2. Adding 0 returned the err variant with "amount must be positive". Adding 3 returned the ok variant with 5.
• getCount returned 5, so the rejected call did not change state.

The output also tells you how to stop the network when you are done. You can open the Candid UI link in a browser to call getLastAmount and whoAmI by hand. For automated tests, the ICP docs cover PocketIC and testing strategies, and mops includes a test runner for Motoko unit tests.

Pitfalls and troubleshooting

Two more notes. First, trapping and returning an error are different. If an update method traps, its state changes are rolled back and the caller gets a reject. Returning #err, as add does, gives the caller a normal reply it can handle. Second, upgrade compatibility checks became stricter in recent releases. Before you change the type of a persistent variable, read our earlier coverage of the upgrade check added in Motoko 1.12.0.

FAQ

What is the Motoko language used for?

You use Motoko to write canisters, the smart contracts of the Internet Computer. It compiles to WebAssembly, generates the Candid interface, and keeps actor state across upgrades without hand-written serialization. Typical uses are app backends, tokens and services that call other canisters.

What does the transient keyword do in Motoko?

In moc 2.0.0, actor variables are persistent by default and survive upgrades. Marking a variable transient opts it out: it goes back to its initial value after each upgrade. Use it for caches, counters you can rebuild, or anything you do not want to keep.

Why can't I index an array with a Nat64 in Motoko?

Array indexes must be Nat, and Motoko does not convert between number types on its own, so a Nat64 index fails with error M0096. Convert it with Nat64.toNat from the core library, or keep indexes typed as Nat.

What changed in RUSTSEC-2026-0334

The advisory, titled "BIP-322 address ownership verification bypass for P2WPKH and P2SH-P2WPKH addresses", was reported on August 14, 2026 and issued on October 9, 2026. It has a CVSS 3.1 score of 9.1 (Critical) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. That means the attack works over the network, is easy to carry out, and needs no privileges and no user interaction.

The bug is in the P2WPKH path. A BIP-322 proof carries a witness, and for P2WPKH that witness contains a signature and a public key. In verify_full, the crate took the public key from the caller-supplied witness and passed it to verify_full_p2wpkh. That function then read the key from the same witness and compared it with itself:

// bip322 0.0.6 to 0.0.10 (from the advisory)
let witness_pub_key = &witness.to_vec()[1];

if &pub_key.to_bytes() != witness_pub_key {
    return Err(Error::PublicKeyMismatch);
}

Both values come from the same witness element, so the check always passed. The crate verified that the signature matched the embedded key. It never checked that the key hashes to the claimed address. In the advisory's words, this violated BIP-322's rule that the signature must satisfy the challenge for "the claimed address's scriptPubKey".

The attack works like this: pick any victim P2WPKH or P2SH-P2WPKH address, build the BIP-322 challenge for that address and a message, sign it with your own unrelated private key, and submit it. The proof is accepted.

The fix is referenced as commit e8accbe in rust-bitcoin/bip322. The verifier now builds the expected scriptPubKey from the witness public key (P2WPKH(HASH160(pubkey)), wrapped in P2SH for the nested case). That script must exactly equal the claimed address's scriptPubKey before signature verification runs. Otherwise verification fails with Error::PublicKeyMismatch.

Who is affected and why it matters

You are affected if your code calls any of these four functions on a version from 0.0.6 up to (but not including) 0.0.11:

• bip322::verify_simple
• bip322::verify_simple_encoded
• bip322::verify_full
• bip322::verify_full_encoded

The risk is highest where a passed check grants something: "Sign in with Bitcoin" logins, proving ownership of a deposit or withdrawal address, airdrop or allowlist claims, and proof-of-reserves tools that accept signed messages. The advisory calls the result a "complete authentication bypass". The attacker needs no victim key and no victim interaction.

Two common assumptions do not protect you. First, application-level nonces do not help, because the attacker signs the current challenge with their own key. Second, the bug is in the P2WPKH and P2SH-P2WPKH paths only. P2TR (Taproot) verification is not affected, because the public key comes from the address's witness program, not from the caller's witness. That is little comfort if your service accepts SegWit v0 addresses at all.

The crate may also reach your build through another dependency, such as a wallet library or an indexer. Check the full dependency tree, not only your direct dependencies.

What to do now

The advisory says "There is no known workaround". Upgrade to 0.0.11.

1. Find every copy of the crate. Run cargo tree -i bip322 in each workspace to see which crates pull it in and at which version.
2. Edit the manifest. Cargo treats a caret requirement on a 0.0.z version as an exact pin. Its docs say ^0.0.3 means >=0.0.3, <0.0.4. So bip322 = "0.0.10" will never resolve to 0.0.11, and cargo update alone will not fix it. Change the requirement:

# Cargo manifest, [dependencies]
- bip322 = "0.0.10"
+ bip322 = "0.0.11"

3. Update the lockfile. Yanking does not remove a version from an existing Cargo.lock, so builds with a pinned vulnerable version keep working until you change them:

cargo update -p bip322
cargo tree -i bip322   # confirm only 0.0.11 remains

4. Handle copies that come in through other crates. If another crate depends on 0.0.6 to 0.0.10, upgrade that crate or ask its maintainers to release a version that requires 0.0.11. Until then, you are still exposed.
5. Add the advisory check to CI. cargo audit reads the RustSec database and fails on RUSTSEC-2026-0334:

cargo install cargo-audit --locked
cargo audit

6. Add a negative test. Sign a challenge for a fixed P2WPKH address with an unrelated key, and assert that verification returns an error. On 0.0.11 it should fail with Error::PublicKeyMismatch.
7. Review past decisions. For any ownership proofs accepted for P2WPKH or P2SH-P2WPKH addresses while a vulnerable version was deployed, check whether the address hashes to the public key in the witness. Revoke sessions or claims that fail that check.

Caveats

On GitHub, the referenced fix commit e8accbe is titled "Add multisig support (#65)". It also adds things that are not part of the security fix, such as a new error for missing private keys. If you call signing APIs as well as the verify functions, read the diff between 0.0.10 and 0.0.11 before you upgrade. With no workaround available, staying on a vulnerable version is not a safe option.

What changed in SP1 v6.9.0

The main SDK change is a public builder for NetworkClient. Pull request #3001 adds optional mutual TLS (mTLS) identity and refreshable bearer-token settings, so a caller can use authenticated Prover Network and Artifact Store RPCs without constructing a NetworkProver. The existing NetworkClient::new() constructor and NetworkProver API stay unchanged, according to the merged change.

The release also includes three performance entries: removing unnecessary data reordering in GPU NTT, simplifying GPU zerocheck constraint evaluation, and improving global trace generation. The NTT change is recorded as merged PR #2990. The release notes do not give before-and-after proving times, so treat these as implementation changes rather than a quantified speed claim.

Two correctness and build items matter to teams compiling or verifying programs. The release says zkvm_bls12_* and zkvm_ripemd160 were made spec conformant. It also says the CLI pins its toolchain with an LTO atomic-lowering fix. That pin is succinct-1.96.0-64bit-v3, as described in PR #3007.

The rest of the release focuses on delivery and CI: upload all release assets before publishing, allow configured runner environments for PR checks, default PR workflow runners to v3, and configure a Go proxy fallback for release builds. The full changelog identifies the comparison as v6.8.1...v6.9.0.

Who is affected and why it matters

The new builder is useful when an application needs to call network or artifact-store RPCs directly through a NetworkClient, without using the higher-level NetworkProver. Before this change, credentials were supported internally but could not be configured through that client's public constructor. Teams that already use NetworkProver can keep that API; the change does not require them to adopt a new client construction pattern.

The authentication options give operators a way to configure mTLS client identity or bearer tokens for those standalone calls. The PR reports that its tests covered both network modes, missing-token rejection, token refresh across client clones, and unauthenticated clients. It also notes that certificate renewal requires creating a new client, while bearer-token refresh can use the existing shared token handle.

GPU prover users should check whether their workloads benefit from the NTT and zerocheck changes, but benchmark their own proving jobs before estimating capacity or cost changes. The release supplies no timing data. Developers who use the affected BLS12 or RIPEMD-160 zkVM operations should review their expected outputs and verifier compatibility after upgrading, since the release specifically calls out spec conformance for those operations.

What to do now

1. Check your dependency and toolchain pins. If you use SP1 crates or the CLI, decide whether to move them to v6.9.0 in your normal dependency update. Keep the version recorded consistently across local development and CI.
2. If you make standalone network calls, inspect the NetworkClient builder documentation and configure only the credentials your service requires. The SP1 docs describe installation through sp1up and checking the installed CLI with cargo prove --version; use your project's existing installation policy when selecting a toolchain. Installation guide
3. Confirm the authentication path in your own environment. In particular, plan client recreation when rotating an mTLS certificate; bearer-token refresh has a different lifecycle.
4. Run your existing proof, verification, and CI checks after the update. Include cases using zkvm_bls12_* or zkvm_ripemd160 if your guest programs call them, and compare GPU proving results on representative inputs before changing operational estimates.

Caveats

The release does not quantify the GPU performance changes. The authentication PR says its TLS tests did not perform an mTLS handshake, so validate the certificate and endpoint behavior in the deployment environment where you will use it. The PR reports 41 network tests and builder documentation checks on Rust 1.98, while full workspace and GPU checks were left to GitHub CI.

Who this guide helps

Use this guide if you have searched “caffeine ai vs lovable,” “vs replit,” “vs base44,” “vs chatgpt,” or “vs claude” and need to decide what to try. By the end, you will have a comparison checklist and a concrete handoff point for bringing a developer into the work.

There is no app-builder version to install for the four hosted products. Product features and plan details change; this guide reflects vendor documentation checked on October 10, 2026. For Base44’s command-line workflow, use Node.js 20.19 or higher, which its CLI docs list as a requirement. Treat Base44’s CLI and backend service as beta, as its docs currently do. You will also need accounts for the service you choose and, if you plan to export or sync code, access to your own GitHub account.

Compare what you get

The key question is what is generated and where the running application and its data live. Vendor descriptions below are product claims; verify plan and deployment details against your own requirements before launch.

Caffeine’s own guide states, “Apps built on Caffeine run on the Internet Computer (ICP).” That is a material architectural difference: Caffeine’s app runtime and app data are connected to ICP, while the other three describe vendor-managed cloud hosting or backends. Caffeine says it uses Motoko for backend code and offers source export. For a working prototype, use its draft/live split: develop and review in draft, then publish the chosen version to live. Its pricing page gives concrete current limits: “15 welcome credits at signup,” “20 credits per month” on Host, and “100 credits per month” on Studio. See How Caffeine Works, plans and pricing, and Caffeine’s canister and SaaS guidance.

Lovable’s main product is a prompt-driven web app builder. Its Cloud documentation describes generated frontend and backend code, a hosted Supabase-based backend, and configurable data region options. The GitHub guide says Lovable can sync changes both ways, but it edits one active branch at a time and does not import an existing repository into a Lovable project. Treat sync as a code workflow; separately plan database schema, data migration, secrets, and deployment when taking over an app.

Replit includes the coding environment alongside generation. Its publishing guide distinguishes Autoscale, Static, Reserved VM, and Scheduled deployments. These affect runtime behavior: static hosting suits browser-only assets; a Reserved VM stays on for workloads such as bots; Autoscale responds to traffic; Scheduled runs tasks on a schedule. Replit’s pricing page lists paid plans and explains that usage and Agent work can involve credits and effort-based pricing. Set a usage limit before open-ended Agent work, and account for deployment costs separately from the plan price.

Base44 spans a prompt-based editor and a developer workflow. Its pricing page says free accounts get 25 message credits and 100 integration credits per month, with a limit of five apps; paid plans raise the allowances. Its CLI overview documents local projects, GitHub integration, an eject option, and deployment of site files and backend resources. The same guide says the CLI and backend service are currently beta, so confirm required capabilities and plan a fallback before depending on them for a production service.

Check login and data before building

Login is a product decision because it shapes the user journey and often the backend. Caffeine’s built-in app login uses Internet Identity and passkeys; its docs say email/password and social login are not supported as built-in methods. This may fit an app whose audience accepts Internet Identity, but test that assumption with actual users before building around it.

Lovable Cloud includes user authentication and storage, and the docs provide settings for sign-in methods and project data region. Replit can generate app code and offers platform services, but the login method depends on the implementation and integrations you choose. Base44 documents customizable login and registration pages, email/password login, and social providers such as Google; its CLI can manage auth configuration. In all four, review authorization rules in the generated app instead of assuming that a working login automatically protects every record.

Data handling differs too. Caffeine says data is stored in the app on ICP, and its SaaS guide cautions that tenant isolation is application-level when tenants share one app. Lovable Cloud exposes database, storage, secrets, and regional settings. Replit recommends using a database or storage product for persistent data rather than relying on the deployed filesystem. Base44 includes a managed database and access controls. Before using real customer data, define who can read, change, export, and delete it, then confirm the platform supports the retention and residency rules your product needs.

Use this decision checklist

1. Name the runtime requirement. If ICP canister execution is part of the product, Caffeine directly targets that runtime. If you need conventional web hosting, compare Lovable Cloud, Replit deployment types, and Base44 hosting against your framework and operations needs.
2. Write down your data and login needs. Record sign-in providers, roles, file access, data region, backups, and migration requirements. Check that generated code enforces these rules server-side.
3. Calculate the usage model. Estimate both build activity and running-app activity. Caffeine, Lovable, and Base44 expose credit allowances; Replit combines subscriptions and included credits with effort-based Agent charges and deployment resource costs. Check current vendor pages before committing spend.
4. Prove the handoff early. Export or sync a small feature, open it locally, and identify which services or credentials still belong to the vendor platform. A source export is not automatically a portable database, hosted service, or user-account migration.
5. Set a developer takeover trigger. Bring in an engineer when the app needs custom authorization, complex transactions, regulated data handling, performance work, independent deployment, or a tested migration path. Make the handoff a planned phase, not a rescue after real users depend on an unreviewed build.

Pitfalls and troubleshooting

A generated app runs, but access rules are wrong. Test with separate accounts for guests, regular users, and admins. Verify backend responses and data permissions, not only which controls appear in the interface. For Caffeine multi-tenant apps, the vendor describes tenant separation as application logic over shared app storage; use separate apps if physical separation is required by your design or compliance needs.

Git sync is mistaken for complete portability. Lovable’s docs say GitHub sync exports and syncs project code, while app hosting and backend services are separate concerns. Base44’s code export likewise does not mean your database and users have moved to another service. Write a migration plan for records, files, identity, secrets, and external API credentials.

The bill is hard to predict. Credits can cover different actions across vendors. Lovable documents one balance used for building, chat, hosting, Cloud, and some AI or connector usage. Replit Agent charges vary with effort, and published compute has its own resource costs. Start with a narrow feature and check the usage page after each build cycle.

The preview behaves differently from production. Caffeine has temporary drafts and permanent live canisters; Replit publishes a separate snapshot; Lovable and Base44 also distinguish editor work from hosted app behavior. Seed test data, check environment-specific secrets, and verify the live login flow before inviting users.

A tool is treated as a framework. These platforms package code with managed runtime and services. If a requirement depends on a particular framework version, database engine, observability stack, or deployment region, check that requirement directly and take over the code before the platform’s defaults become hard to replace.

FAQ

Is Caffeine better than Lovable for an ICP app?

Caffeine explicitly runs apps on ICP as canisters. Lovable documents hosted web apps and a Supabase-based Cloud backend. Choose based on the required runtime and user identity model; neither vendor documentation supports a universal ranking.

Is Caffeine the same as ChatGPT or Claude?

No. Caffeine is an app builder that generates and hosts an app on ICP. Lovable documents a ChatGPT integration that creates a starting project, then sends iteration to Lovable. Base44 documents CLI and coding-agent workflows that can be used with agents such as Claude Code. ChatGPT and Claude can assist with planning or coding, but the hosting and backend choice remains a separate decision.

When should I take over the generated code?

Take it over when you need reviewable authorization, custom architecture, predictable deployment control, or a data migration plan. Export or sync to GitHub, run a code review, inventory platform dependencies, and test a staging deployment before moving production users.

What changed: the failure is in timer dispatch

The thread began with a developer reporting that timers stopped after a canister froze for lack of cycles and did not resume after a top-up. The developer said this had happened “around 15 times” and described cases where recovering an older canister meant rebuilding and upgrading it. The thread proposed a platform behavior called “cryostasis”: retain timers during a freeze and resume them when the canister can run again.

Later replies narrowed the issue. A post on August 13 said a pending global timer should be retained while the canister is frozen, then run after a top-up. It also pointed to a Motoko timer failure path: the global timer fires, Motoko sends a self-call to run the helper, and that call can be rejected for lack of cycles. If the helper never runs, it cannot schedule the next timer. The queue may remain in memory, but no timer is left to wake it.

On October 7, the thread author pointed to Motoko pull request #6440 as the fix in progress. The PR adds a fallback global timer for the default Motoko timer handler, set to “now + 5 seconds” before it sends the helper call. If the helper call is rejected, the fallback can fire again after the canister receives cycles. The helper replaces the fallback with the next actual deadline when it runs.

The PR also changes how the helper handles one-shot jobs. It reinserts a job if its self-call is rejected with #system_transient, which indicates the job did not run. Recurring jobs are already rescheduled, so the fix skips missed runs instead of replaying them after recovery. This is a Motoko runtime fix, not a change to the Internet Computer protocol’s global timer rules. The IC interface specification says the global timer is deactivated when a canister runs out of cycles and must be set again for canister_global_timer to be scheduled.

Who is affected and why it matters

The immediate audience is teams using Motoko’s default timers for scheduled work. A helper self-call can fail asynchronously after being sent, so code that only handles an immediate failure may miss the rejection. The result can look like a timer queue was erased: funding the canister restores its ability to run, but without a scheduled wake-up the helper does not execute to resume the queue.

This can delay recurring maintenance and one-shot work in applications that depend on timers. The fix’s retry policy also matters: one-shot jobs rejected before execution are reinserted, while recurring jobs skip the missed invocation and continue their schedule. Developers should account for that behavior in jobs that must process every interval or catch up after an outage.

The forum thread also includes a separate Rust CDK diagnosis. A Rust developer reported a reproduction on “PocketIC 15” with “ic-cdk 0.19” and “ic-cdk-timers 1.0.0”; they found that calling set_timer_interval again could be a no-op when the CDK cache held an earlier deadline. They recommend a raw global timer reset for that Rust case. This is useful context, but it is not the Motoko PR’s fix and should not be applied as a generic Motoko recovery recipe.

What to do now

1. Check the status of Motoko PR #6440 before planning an upgrade. As of October 9, it was open and awaiting a requested review; there was no released compiler version containing the fix.
2. For affected Motoko deployments, keep an external check on cycles and on whether timer-driven work is advancing. The thread suggests exposing a timer counter or timestamp that an outside monitor can read, since a canister with a dead timer cannot report its own failure.
3. Review timer callbacks for missed-run behavior. Make callbacks safe to retry, and decide whether a missed recurring interval should be skipped or recovered through separate application state.
4. After the PR is merged and included in a Motoko release, build and deploy with that release, then verify behavior on a test canister that is starved of cycles and topped up. The PR describes tests for rejected helper calls and one-shot jobs; do not assume those changes are already in a published compiler.

The official upgrade guidance separately warns that timers are deactivated during upgrades and need to be set up again. Treat upgrades and low-cycle recovery as distinct paths when reviewing timer initialization and recovery logic.

Caveats

PR #6440 was still in review on October 9, 2026. Its described fix targets Motoko’s default timer handler; the PR explicitly leaves user-defined system func timer behavior for separate work. The forum discussion also records different observed behavior across environments, so the thread does not establish that every frozen canister loses timers in the same way.

What the thread found

The discussion began with a specific concern: threshold signing can keep private keys out of a central operator’s hands, but users still interact with a browser frontend that builds transactions and holds an authenticated session. If someone can change the JavaScript served from a trusted origin, that code may be able to act with the session’s permissions. Internet Computer security guidance describes this class of risk: a malicious frontend can control a user’s session and assets available through it. Canister control guidance

A later forum reply reports that OISY’s production Internet Identity derivation origin is https://oisy.com, and that its canister URL is configured as an alternative origin. The reply summarizes the consequence as “Same backend accounts, same chain-fusion addresses.” This is the participant’s reading of OISY’s configuration, not an official DFINITY statement about the wallet. Forum thread

That matters because Internet Identity derives a user identity from the frontend origin. Its specification says, “A user has a separate user identity for each client application frontend (i.e., per origin).” The origin is therefore part of the identity users bring to the application. A valid login session proves that calls are authorized by that identity; it does not prove that the JavaScript displaying or constructing those calls is safe. Internet Identity specification

The forum reply also distinguishes canister control from domain control. It states, “There is no consensus, no proposal and no on-chain record saying ‘this domain changed hands’.” A canister may serve certified assets, but that certification checks the response from the canister reached. It does not independently establish that a custom domain’s DNS still points to the intended canister. The IC documentation similarly warns that a developer controlling a registered custom domain can point it at a different application, even one outside ICP. Canister control guidance

Who is affected and why it matters

Wallet teams and any dapp that asks users to authenticate should treat the frontend origin as part of the security design. The concern extends to Chain Fusion applications because a browser session can request actions from canisters, including signature operations, within the permissions granted to that caller. A threshold signer protects key material; it does not by itself protect the interface that asks the signer to act.

Custom domains offer familiar names and a smoother user experience. They also add registrar and DNS accounts to the set of systems that can affect what users load. Native canister URLs reduce that per-app DNS dependency because the hostname includes the canister ID. They still depend on the shared gateway domain and gateway verification, so this is a narrower trust model, not a trust-free one.

Changing the canonical origin has a user impact: because Internet Identity derives identities per origin, users may receive a different principal after a change. Applications that already hold balances or account state under the old principal need a migration plan. The forum discussion raises these risks and asks for DFINITY’s clarification; it does not establish who administers OISY or NNS domains, or set a new official recommendation.

What developers should do now

1. Inventory origins. Record the login origin, any derivationOrigin, alternative origins, and the domain and DNS accounts that control them. Verify that every alternative origin is under your control; the Internet Identity specification warns against allowing third parties to share principals.
2. Choose the canonical origin before launch. For a new security-critical app, assess a native canister URL as the derivation origin. If you choose a custom domain, document who controls its registrar and DNS and include account recovery and access review in your security process.
3. Keep frontend delivery verifiable. Serve browser assets from certified canisters, avoid untrusted external scripts, and set a content security policy. These steps protect asset delivery and reduce third-party code risk, while leaving DNS ownership as a separate consideration.
4. Plan origin changes as identity migrations. Before changing a live app’s derivation origin, identify the principals and assets affected, test account recovery and migration paths, and communicate the change to users. Do not assume that signing in with the same Internet Identity anchor preserves the same app principal.
5. Give users a clear verification path. Publish the expected origin and canister ID, and tell users where to find the native canister URL. For high-value actions, consider a confirmation flow that shows transaction details independently of the page that constructs the transaction.

Treat the domain, frontend code, canister controllers, and transaction confirmation path as separate controls. Reviewing each one makes it easier to see where trust rests and what a compromise could change.

What changed in wasapi 0.25.0

Before the fix, WaveFormat::parse accepted a safe reference to WAVEFORMATEX. That C-compatible header is 18 bytes. If its wFormatTag was WAVE_FORMAT_EXTENSIBLE and its cbSize was at least 22, the function treated the reference as a 40-byte WAVEFORMATEXTENSIBLE and read the additional fields. A reference to the header alone does not promise that those bytes exist after it, even if the cbSize field says they should.

The advisory provides an example with cbSize: 22: calling WaveFormat::parse(&header) can read 22 bytes past the end of that header. A realistic route is copying a header from a WASAPI format pointer, for example let fmt = unsafe { *ptr };, then parsing &fmt. The copied value retains cbSize, but not the extended data that followed the original pointer. RustSec says those out-of-bounds bytes are returned as the parsed channel mask and subformat.

The fix is commit 2562db7, included in version 0.25.0. The parser now takes a *const WAVEFORMATEX and is an unsafe fn; callers must ensure the pointer is valid for size_of::<WAVEFORMATEX>() + cbSize bytes. The safer alternative, WaveFormat::parse_from_blob_bytes, has been available since 0.23.0 and checks that the byte slice is long enough for cbSize. The merged wasapi pull request #64 confirms the parser API change and identifies the blob function as the safe alternative.

Who is affected and why it matters

The affected range is >=0.20.0, <0.25.0; versions <0.20.0 are listed as unaffected, and >=0.25.0 is patched. The advisory names Windows as the affected OS. Check the version actually resolved by your application or library: a direct dependency declaration may not show the version Cargo selected for the build.

This is a soundness issue in a safe API. Code using the old method did not need an unsafe block to reach the read, so callers could not express or check the missing buffer-length guarantee at the call site. In practice, the read can expose adjacent memory values through the returned format fields. The advisory does not report a separate exploit or claim that every call triggers the read; the unsafe path depends on an extensible format header and its cbSize value.

The 0.25.0 API change makes the caller responsible for pointer validity when choosing the raw-pointer parser. That responsibility is meaningful: adding an unsafe block around a pointer to a copied 18-byte header does not restore the missing 22 bytes. Existing code that parses a standalone header should migrate to a byte slice that includes all bytes declared by the header, or retain the full WASAPI-provided buffer and pass that to the safe parser.

What to do now

For code that already has the complete format data as bytes, use the safe method in wasapi 0.25.0:

// wasapi 0.25.0; `blob` must contain the complete format data.
let format = wasapi::WaveFormat::parse_from_blob_bytes(&blob)?;

The method accepts a potentially unaligned byte slice containing a WAVEFORMATEX or WAVEFORMATEXTENSIBLE. This also matches the crate's documented approach for parsing a WASAPI device-format blob: keep the data as bytes instead of creating a reference to a header whose allocation may not include its extension. See the wasapi 0.25.0 API documentation.

Use this migration checklist:

1. Inspect your dependency tree and identify every resolved wasapi version. Update Windows builds that use a version from 0.20.0 through 0.24.x to at least 0.25.0.
2. Find calls to WaveFormat::parse. If the input is a complete format blob, switch to parse_from_blob_bytes(&blob) and handle its Result as shown above.
3. If you must use the raw-pointer parse in 0.25.0, prove at the call site that the allocation spans the 18-byte header plus the number of extension bytes in cbSize. Keep the complete WASAPI allocation alive for the call; do not pass a pointer to a copied header by itself.
4. Review wrappers around wasapi as well as direct application calls. A wrapper that still accepts only &WAVEFORMATEX cannot establish that extended bytes are present.

The key change is both a patched version and a type-level warning: callers now see that pointer parsing requires an unsafe choice. For ordinary blob input, the checked slice parser avoids putting that pointer-length proof on each caller.

This guide is for developers moving projects from moc 1.x to 2.0.0. You will finish with a source and deployment checklist for one canister upgrade. You need the Motoko 2.0.0 compiler, your project’s existing build setup, and access to the canister’s current stable signature or source. If you deploy with ICP CLI, use the version already pinned by your project and verify it with icp --version.

The Motoko 2.0.0 migration guide is the main reference for the source changes and compiler checks below. This is a follow-up focused on those steps; the earlier Motoko 2.0 upgrade overview covers the release at a higher level.

What changes for an existing canister

In Motoko 2.0, fields in a bare actor or actor class persist across upgrades by default. A field marked transient is initialized again on upgrade. For example, a cache or function value that should not survive a code change needs that modifier:

actor {
  var accountCount : Nat = 0; // retained across upgrades
  transient var cache : [Nat] = []; // initialized again on upgrade
  transient let log = func (message : Text) { Debug.print(message) };
};

This default is a source-level change with a runtime consequence. If a project previously compiled with --legacy-actors, unmarked fields were transient. In 2.0, those fields become persistent unless marked transient. Non-persistable fields, such as functions or objects with methods, need transient; otherwise compilation reports an error. Fields that become persistent are treated as new stable fields on their first upgrade, so their initializer runs then, and their value is retained by later upgrades. These rules are described in the moc v1 to v2 migration guide and the Motoko data persistence docs.

Existing source that already declares persistent actor generally follows the new default already. In 2.0, persistent and stable become redundant, with compiler warnings suggesting they can be removed. Removing them does not change the stable signature. The keyword flexible, previously an alias for transient, is removed; replace it with transient.

The one-way persistence migration

First determine how the deployed canister was compiled. Motoko 2.0 cannot produce a classical-persistence canister, but it can upgrade an existing one. On that canister’s next upgrade to enhanced orthogonal persistence (EOP), the transition is one-way: later upgrades cannot return to classical persistence.

For that single transition, compile with --enhanced-orthogonal-persistence and without --enhanced-migration. Otherwise the upgrade traps with Detected implicit upgrade from classical orthogonal persistence to enhanced orthogonal persistence, and combining the transition with --enhanced-migration traps too. Later upgrades need neither flag. For a canister already using EOP, the flag is accepted but does nothing. The 2.0.0 release notes state that EOP retains persistent 64-bit main memory and uses incremental garbage collection; they also say classical persistence and the other garbage collectors are removed.

On ICP, EOP depends on retaining the WebAssembly main memory during an upgrade. The platform upgrade option for this is wasm_memory_persistence = opt keep. The EOP documentation explains that this option is required for EOP and warns that replace drops Wasm main memory. Use a deployment tool that supports the EOP upgrade metadata; do not construct a custom install call that replaces memory.

Pre-upgrade checklist

Follow these steps for each canister before releasing the Motoko 2.0.0 build.

1. Build with your last 1.x compiler and clear its deprecation warnings. The migration guide specifically recommends building cleanly with the latest 1.16.x first. Fix .vals() warnings by using .values(), and plan to replace preupgrade and postupgrade hooks with a migration function where they are used. This separates existing cleanup from errors introduced by the compiler upgrade.

2. Pin the compiler. In mops.toml, set the toolchain version so local and CI builds use the same release:

   [toolchain]
   moc = "2.0.0"
   

3. Audit state declarations. Review every let and var inside actors and actor classes. Mark caches, function values, version-specific values, and other state that should reset with transient. Replace each flexible keyword. Persistent collections can remain ordinary fields if their types support persistence. Check any legacy actor flags carefully because their old default made unmarked fields transient.

4. Remove options and APIs that 2.0 no longer supports. Remove --default-persistent-actors, --require-persistent-actors, and --legacy-actors. The release also removes --legacy-persistence, --copying-gc, --compacting-gc, --generational-gc, --rts-stack-pages, --skip-gc-deprecation-warning, --incremental-gc, and --experimental-rtti; these are rejected as unknown options. The flexible keyword and ExperimentalStableMemory/Prim.stableMemory* APIs are removed too. Replace ExperimentalStableMemory use with Region, as appropriate for your project.

5. Run the project checks and address errors. Use the commands in the project’s Motoko toolchain. For the migration-guide workflow:

   mops check
   mops check-stable
   

   The migration guide also documents checking signatures directly with moc:

   moc --stable-compatible old.most new.most
   

   Use the signatures from the deployed and proposed versions. The compatibility check catches incompatible stable declarations; it does not replace reviewing the public Candid interface or testing the upgrade path.

6. Build with the correct transition flags. If the deployed canister still uses classical persistence, compile this upgrade with --enhanced-orthogonal-persistence and omit --enhanced-migration. For a canister already on EOP, the flag is redundant. If you use enhanced migration, it no longer requires the EOP flag, but do not combine that migration mode with the one-time classical-to-EOP transition.

7. Deploy explicitly as an upgrade and verify the canister. With ICP CLI, build and request upgrade mode using the documented commands:

   icp build
   icp deploy my-canister --mode upgrade
   icp canister status my-canister
   

   Replace my-canister with the configured canister name. ICP CLI documents that upgrade mode preserves stable state; the Motoko release guide explains the compiler-side migration requirements. Check the canister’s expected state through its own query methods after deployment. Consult the canister lifecycle guide for the CLI upgrade flow.

Pitfalls and troubleshooting

The upgrade traps with "Detected implicit upgrade from classical orthogonal persistence". Confirm that this is the intended one-time transition. Compile that upgrade with --enhanced-orthogonal-persistence, without --enhanced-migration, and preserve the resulting toolchain configuration for later releases.

A value unexpectedly survives an upgrade. Find the field declaration and mark it transient if it must reset. Pay special attention to projects that previously used --legacy-actors; the old default does not carry into 2.0.

A value unexpectedly resets. Check whether the field is explicitly or implicitly transient, and confirm the deployed version and new stable signature. New persistent fields initialize on their first upgrade; existing persistent fields are carried forward only when their stable representation is compatible.

The build rejects a removed option or feature. Search compiler arguments in project configuration and CI scripts, not only source files. Replace flexible with transient; replace removed stable-memory primitives with the Region API. Keep an older compiler only if you must continue producing classical modules.

A compatibility check passes but the upgrade still needs review. Stable compatibility is one part of upgrade safety. Review the Candid interface, migration behavior, and post-upgrade application state, and keep a recovery path. The EOP docs recommend testing upgrades and maintaining a way to recover data, such as controller-privileged data queries.

FAQ

Does Motoko 2.0 preserve variables in a bare actor?

Yes. Actor fields persist across upgrades by default. Add transient to each field that should be initialized again after an upgrade.

Can I switch a canister back from enhanced to classical persistence?

No. The classical-to-EOP move happens on the canister’s next upgrade using the Motoko 2.0 transition flag and is irreversible. Later upgrades need no transition flag.

Which check should I run before deploying?

The moc v1-to-v2 guide documents mops check-stable and moc --stable-compatible old.most new.most. Run the project’s check, review Candid compatibility, then deploy with ICP CLI’s explicit upgrade mode.

ic-reactor is developed by B3Pay, which also publishes this blog.

What changed in ic-reactor 4

ic-reactor 4 is a breaking rewrite of the library for TypeScript and React applications. Instead of generating React hooks, developers generate a TypeScript module from each canister’s .did file with candid-core-cli gen, then bind its actor type to a client. The client builds options for TanStack Query’s own useQuery, useMutation and suspense hooks. The release puts three packages at the same version: @ic-reactor/core, @ic-reactor/react and @ic-reactor/vite-plugin.

An app creates a client with a network and identity or auth provider, then calls client.canister<Actor>(actor, { id }) or resolves a canister by name. The returned canister has plain async methods. For React reads and writes, client.queryOptions(canister, method, args) and client.mutationOptions(canister, method) feed the standard TanStack hooks. A Candid result variant with Ok or Err resolves to the Ok value or rejects with the Err value.

The cache key includes the network, caller principal, canister ID, method and arguments. That caller-scoped key prevents one principal’s cached response from being shown to another. Each principal also has an immutable agent. If a read started under one account settles after sign-in, sign-out or an account switch, it rejects as cancelled rather than populating the new caller’s cache.

Write failures carry a ReactorError with a mayHaveExecuted flag. It tells the app whether a failed write may still have changed canister state. The client re-sends an update only when it has proof that the canister never received it, such as reject code 2 or HTTP 429, at most twice within the call. TanStack Query itself does not retry mutations. Reads retry up to three times only for not_delivered, and never on a server. A write is refused before sending if nobody is signed in; a successful write invalidates reads for that canister by default.

Beta.2 adds the canister_not_found error code for calls routed to a missing canister, lets createTestClient().refuseNext() target a method or canister, and improves types so eligible queryOptions can be passed to suspense hooks without a cast. It also pins @candid-core/schema at 0.3.0 and @candid-core/cli at 0.2.0. The release notes say beta.1-generated modules need no regeneration for those pins. See the release and v4 changelog for the precise type-level changes.

Who is affected and why it matters

This release is for teams starting a new integration or evaluating a migration. TanStack Query owns the hook behavior, while ic-reactor supplies canister-aware options, caller-scoped caching and consistent errors. Apps can use the same read and mutation patterns as other TanStack Query data, while still handling the different risks of canister updates. For example, if a transfer error says it may have executed, an app can re-read the balance before offering another attempt; if the flag is false, the transfer had no effect.

Existing 3.x applications do not upgrade in place. The 4.0 API removes reactors, hook factories and generated hooks, and changes the Candid value types to follow candid-core: principals are branded text, optional values use T | null, variants use { tag, value }, and blobs are Uint8Array. The migration guide lists removed 3.x names and their replacements. The latest npm tag remains on 3.x, currently 3.13.0, until 4.0 GA; no GA date has been announced. Version 3.x receives security fixes only until then, and its documentation remains under /v3/.

Four example apps on the v4 branch cover a mainnet ICP ledger and fault-injecting sandbox, a React wallet on a local network, server rendering with one client per request, and a command-line agent tool. The examples and the v4 docs give developers starting points for browser, server and test setups.

What to do now

To evaluate beta.2, install the beta packages and the exact stable candid-core pair. These commands apply to ic-reactor 4.0.0-beta.2:

npm install @ic-reactor/core@beta @ic-reactor/react@beta @icp-sdk/core @tanstack/react-query
npm install --save-exact @candid-core/schema@0.3.0
npm install --save-dev --save-exact @candid-core/cli@0.2.0
npm install --save-dev @ic-reactor/vite-plugin@beta

Then generate each canister’s module from its .did file and port calls to the client. A balance read can use TanStack Query directly:

import type { Principal } from "@candid-core/schema"
import { formatUnits } from "@ic-reactor/core"
import { useClient } from "@ic-reactor/react"
import { skipToken, useQuery } from "@tanstack/react-query"
import { actor, type Actor } from "./generated/icrc1"

export function Balance({ owner }: { owner: Principal | undefined }) {
  const client = useClient()
  const ledger = client.canister<Actor>(actor, { id: "ryjl3-tyaaa-aaaaa-aaaba-cai" })
  const balance = useQuery(
    client.queryOptions(ledger, "icrc1_balance_of", owner ? { owner, subaccount: null } : skipToken)
  )
  return <p>{balance.data === undefined ? "…" : formatUnits(balance.data, 8)}</p>
}

A transfer uses mutation options from the same client:

import { useClient } from "@ic-reactor/react"
import { useMutation } from "@tanstack/react-query"
import { actor, type Actor, type TransferArg } from "./generated/icrc1"

export function Send({ arg }: { arg: TransferArg }) {
  const client = useClient()
  const ledger = client.canister<Actor>(actor, { id: "ryjl3-tyaaa-aaaaa-aaaba-cai" })
  const transfer = useMutation(client.mutationOptions(ledger, "icrc1_transfer"))
  return <button disabled={transfer.isPending} onClick={() => transfer.mutate(arg)}>Send</button>
}

When the transfer fails, transfer.error is a ReactorError. If error.mayHaveExecuted is true, the transfer may have gone through, so re-read the balance before offering a retry. If it is false, the transfer certainly had no effect. For a 3.x app, stay on 3.x for now or use the migration table to scope a separate port; a plain install without a beta tag still selects 3.x.

What changed in the September 30 update

ICfirewall is a canister-based relay between a client, such as a web interface or Apple Shortcut, and a local model runner. The canister receives prompts, applies filtering rules, and places approved requests in a queue; a local Python process polls the queue, sends the prompt to a model, and returns the response. That design connects a locally hosted inference process to an Internet Computer canister, which stores and processes the relay’s state.

In the September 23 forum post, the author described “3 modes of off,medium and on” and said users could access the relay through Apple Shortcuts or the frontend chat box. The September 30 update added Internet Identity login. The author says users copy their PID into poll_llm.py to become the master PID, add admins, and change limits; “master pid is the only one who can change modes.” The frontend also now displays both prompt and response.

The update was prompted by interest in the repository: the author wrote, “over 300 clones.” That figure is the author’s report, not a repository download count verified by GitHub. The project README describes three modes—Off, Medium, and On—and lists a canister, a local daemon, and a web interface as its main parts. The project repository currently lists dfx v0.15.0 or higher, Python 3.10+, and a local LLM runner such as Ollama or LM Studio.

Who should care, and what the design means

ICfirewall is aimed at developers who want to keep inference on a local model while routing prompt submission through a canister-managed relay. A central relay can make it easier to inspect and control what enters a model, and its three modes offer different filtering choices. That can be useful for experiments where prompts arrive through multiple clients or where an operator wants to restrict certain inputs.

But the relay does not make local inference safe by itself. Its protection depends on the code that checks prompts, the correctness of identity and permissions, and the way the daemon handles queued work. A commenter pointed out that a regular expression can miss command variants; the author agreed that the rules need improvement and described the project as a sample rather than a bulletproof system. The author also said an AI agent reported that it did not work and that they still needed to test it themselves.

There is a practical configuration mismatch to check: the forum describes the newer Internet Identity and PID flow, while the repository README still documents a bearer-token setup for its Shortcut and daemon. Review the current code and configuration before treating the forum’s update as a complete security change. Prompts and responses also pass through the canister in this architecture, so consider what data you are willing to route through it.

This is relevant to the broader problem of AI coding systems producing unsafe or fabricated outputs. ICfirewall focuses on filtering prompts and model responses, but it should be evaluated as one control in a larger review process.

How to evaluate it locally

The repository’s quick start gives these commands for a local deployment. It lists dfx v0.15.0 or higher and Python 3.10+ as prerequisites; use a local model runner as well. The official dfx deploy reference explains that deployment creates, builds, and installs the canisters defined by the project.

git clone https://github.com/iTechBod/ICfirewall.git
cd ICfirewall
dfx start --background
dfx deploy

Before connecting a model, review the project’s current setup rather than copying old configuration values blindly. The repository README has instructions for setting a canister ID in main.js and starting scripts/poll_llm.py with ODYSSEUS_SESSION_ID; compare those steps with the newer PID flow described in the forum update. Do not deploy to mainnet until you understand which canister methods are public, how administrators are authorized, and what prompt and response data the canister stores.

A useful evaluation checklist is:

1. Run the project against a local replica and a disposable local model.
2. Inspect the canister’s authorization checks and confirm that a non-admin PID cannot change limits or modes.
3. Test benign prompts, malformed input, and prompt-injection attempts against each mode; review both the accepted prompt and returned response.
4. Confirm how the daemon authenticates, polls, and handles errors before connecting it to a model or client you depend on.

The README describes the intended workflow, while the forum thread records the author’s update and acknowledged limitations. Treat both as implementation claims to verify in code, not as evidence that the filter blocks attacks reliably.

The release also removes classical 32-bit orthogonal persistence from moc. New builds target enhanced orthogonal persistence with persistent 64-bit main memory and incremental garbage collection. This aligns the compiler with the Internet Computer’s current persistence model, in which compatible program memory can be retained across upgrades instead of being reconstructed through the older serialization path.

Existing classical canisters are not stranded, but their first upgrade into enhanced orthogonal persistence is a one-time migration. Motoko’s release notes require that upgrade to be compiled with --enhanced-orthogonal-persistence and without --enhanced-migration; later upgrades need neither flag. The migration is irreversible. Caveat: this transition should be rehearsed against a copy of production state and backed by a recovery path, because the official documentation recommends thorough upgrade testing and warns against configurations that can drop Wasm main memory.

The compatibility surface is broader than persistence. Motoko 2.0 promotes several diagnostics from warnings to errors, including non-exhaustive patterns, accidental Any or None inference, constant-result comparisons, malformed enhanced-migration files, bare imported declarations, and actor classes that omit an async return type. It also removes ExperimentalStableMemory in favor of Region and treats flexible as an ordinary identifier rather than a persistence modifier.

There are ergonomic changes too: if, while, switch, and for heads can omit parentheses; switch cases accept lighter pattern syntax; and the ?? operator now depends on whitespace. These changes may look cosmetic, but they can expose latent parsing or type-checking assumptions during a migration.

The practical release workflow is therefore compiler-first: pin moc 2.0.0 in a branch, run the v1-to-v2 migration guide, compile every canister, classify new errors, and test upgrades with representative state. Developers should also verify Candid and stable-state compatibility before deployment. Enhanced persistence can reject incompatible state changes and roll back the upgrade, but that safety mechanism does not remove the need to understand which fields are meant to survive.

Motoko 2.0.0’s headline is persistence by default. Its deeper change is that upgrade behavior is now more explicit: state ownership, migration intent, and previously tolerated mistakes must be visible in source and build checks.

That is the problem LayerZero Research is addressing in Jolt, a RISC-V zkVM used in the Zero proving stack. On September 23, the team announced that Jolt’s bytecode-expansion layer had been formally verified with the Lean theorem prover. The work checks that sequences of Jolt instructions faithfully simulate the RISC-V instructions they replace.

Why bytecode expansion matters

Jolt does not implement every RISC-V instruction directly. For instructions outside its native decomposable set, it emits a sequence of Jolt instructions. This translation is called bytecode expansion. The prover then works over the expanded program.

That creates a sharp correctness boundary: if expansion changes the program’s behavior, the resulting proof can be sound for the wrong computation. Random tests can find examples of failure, but they cannot establish equivalence for every input. A formal proof can, provided its definitions, reference model, and assumptions are correct.

LayerZero’s released repository describes a Lean model of the Jolt instruction set and a trusted RISC-V reference model. It reports that 60 of 67 expandable RISC-V instructions have been proven, while seven remain unproven. The project also documents the assumptions behind each theorem and separates what is proved from what remains trusted.

What developers should take from it

For teams building verifiable applications, the important change is not simply that “Jolt is formally verified.” It is that a previously implicit part of the proving pipeline now has an inspectable correctness argument.

That suggests a practical review checklist for any zkVM integration:

• Identify the exact guest-to-VM translation layer.
• Ask which instruction mappings are formally proved and which are covered only by tests.
• Read the trusted reference model and theorem assumptions.
• Confirm whether the proof covers the cryptographic commitment scheme, verifier implementation, compiler, and host orchestration—or only the execution front end.

The milestone does not remove those other obligations. LayerZero says verification of the remaining Jolt components is still in progress, and the Jolt documentation continues to label the implementation as alpha and unsuitable for production use. The seven unproven instruction expansions are another concrete boundary that downstream users must understand before relying on them.

For ICP developers evaluating a zkVM-backed canister or cross-chain verification service, this is a useful design signal: treat the instruction-expansion specification as part of the security artifact. A proof-system benchmark can show speed and proof size; a machine-checked front-end proof addresses a different question—whether the circuit is proving the computation the developer intended.

That matters because the gap is not simply about adding another elliptic curve. ICP’s current Chain Fusion signing stack is centered on threshold ECDSA over secp256k1, the curve used by Bitcoin and Ethereum. P-256 would target a different compatibility frontier: web authentication, enterprise identity, certificates, and protocols that commonly expect ES256 signatures.

The project’s earlier technical explanation is cautious. DFINITY said the underlying cryptographic protocol already supports P-256, while integration remains necessary across higher layers including consensus, execution, and governance. It also said that governance proposals would be required to generate and back up threshold keys, with no precise production timeline at that point.

Proposal 144212 therefore looks best understood as an infrastructure checkpoint. A test master key can validate key generation, subnet operation, signing behavior, and the operational path for future key backup. It does not by itself make P-256 available to arbitrary canisters or establish a production signing key.

That distinction is visible in the current documentation. The IC interface specification recognizes P-256 for ordinary ECDSA signatures and WebAuthn-related verification, but the Chain-key cryptography guide lists deployed threshold ECDSA keys only for secp256k1. In other words, ICP already speaks P-256 in parts of its interface and identity stack; the open Chain Fusion question is whether canisters can obtain threshold-generated P-256 signatures under the network’s distributed key-management model.

For developers building decentralized certificate authorities, OAuth-related flows, DPoP, JWT integrations, or other web-facing authentication systems, the test-key proposal is an encouraging signal—but not yet an API contract. The next meaningful evidence will be a successful test deployment followed by documented management-canister support, key backup, governance activation, and a clearly identified production key.

The October 5 forum update links the work to Proposal 144212. A separate NNS proposal, 144213, concerns an NNS canister upgrade and is adjacent governance activity rather than evidence that P-256 signing is already generally available.

The key takeaway is simple: P-256 has moved from roadmap discussion toward controlled network testing. Chain Fusion gains a possible bridge to mainstream web cryptography only after the test path becomes a supported, governed production service.

The practical problem is familiar: stable Rust can use a const parameter such as N or a fully concrete expression, but it cannot generally express type-level values such as [u8; N + 1] or [u8; T::NUM_BYTES]. That gap limits fixed-size abstractions and has pushed some libraries toward type-level-number crates.

GCA approaches the problem by making the supported expression category explicit. With the experimental gca_adts feature, arrays, tuples, structs, and enum values involving generic parameters can be passed through gca!(...). A simplified example is a const argument such as gca!([N, 12]), where N is itself generic. The same design also introduces const-item paths for more indirect cases, including associated constants and generic const items.

That explicitness is a safety and compatibility decision, not merely a syntax preference. The project group says gca!(...) arguments have different rules from ordinary const arguments: they can refer to generic parameters, but they currently support fewer expression forms. Arithmetic and function calls, for example, are not directly accepted inside the macro. Other experimental features can route such expressions through const items.

The hardest issue is equality. Once a value participates in a type, the compiler must decide when two const expressions describe the same type. The current tracking issue describes GCA as relying on definitional equality unless const evaluation can establish a result. It also lists unresolved questions around the boundary between opaque equality and richer future reasoning, such as recognizing mathematical equivalences.

This matters for systems code. A library that encodes packet widths, protocol layouts, or serialized representations in types could eventually express more of its invariants without duplicating arithmetic in runtime code. But public APIs would need careful review: changing whether a const item is transparent or opaque can affect what the compiler can prove about type equality.

The near-term message for Rust developers is therefore “experiment, don’t depend.” GCA is still experimental nightly functionality, and the tracking issue remains open with implementation, documentation, style, and stabilization work listed ahead. The project group also acknowledges that the visible gca!(...) syntax creates ergonomic problems and that the macroless alternatives are not yet recommended.

For developers maintaining generic fixed-size APIs, the useful test is small: try the nightly feature gates in an isolated branch, inspect type-equality failures, and keep a stable-compatible fallback. GCA may become a cleaner foundation for const-heavy abstractions, but today its most important contribution is a clearer design boundary for deciding which compile-time values Rust’s type system is allowed to understand.

Recent changes in the dfinity/cksol repository move deposits toward a sweep-based lifecycle. A user calls deposit_sol, the minter queues the deposit, and a timer sweeps funds from deposit addresses into the minter’s main Solana address. The sweep can batch as many as 10 deposits, while the source addresses retain the Solana rent-exemption balance.

The important boundary arrives after the transaction is finalized. In merged PR #222, the minter fetches the finalized transaction, compares the executed message with the plan it recorded, checks the deposit-address balance changes, confirms that the source accounts remain rent-exempt, and verifies that the main address received the expected amount. Only then does it record the credited sweep and queue the corresponding mints.

That design makes transaction metadata part of the accounting path. The minter does not treat a submitted signature as proof that the intended transfer happened. It uses the finalized transaction’s execution data to reconcile what actually arrived before minting an ICP-side token backed by SOL.

The change also addresses a subtle Solana failure mode. A deposit address cannot simply be drained below the minimum balance needed to remain on-chain. The ckSOL design therefore leaves the rent-exemption amount behind and uses the sweep fee model to calculate what can safely move. Solana’s documentation describes this minimum balance as a refundable storage requirement tied to account size.

The repository’s error handling is equally notable. Open PR #218 proposes dropping deposits from failed or expired sweeps so they can be queued again, while quarantining finalized sweeps whose metadata contradicts the minter’s model. In that case, nothing is minted and the deposit requires manual intervention. This is a deliberate preference for a visible operational exception over silent accounting.

There is also a key security correction in merged PR #227: the minter’s main Solana address is separated from user-derived deposit addresses. The change prevents the treasury address from being mistaken for a user deposit account and avoids a self-sweep that could double-count funds.

For Chain Fusion developers, the lesson is practical. Cross-chain minting should be treated as a reconciliation problem, not merely a signing problem. The remote chain’s finalized state, fee behavior, rent rules, and address-derivation scheme all belong inside the canister’s accounting contract.

At verification time, these are repository developments rather than a production launch: PR #218 remains open, PR #221 remains a draft, and the repository states that the production minter and ledger are not yet deployed. The direction is nevertheless clear: ckSOL is making the Solana transaction itself the evidence required before ICP credits value.

The product’s distinctive organizing idea is the “card × grade atom.” PHASMA says these units feed a ledger-style roll-up, allowing values, populations, and indices to be evaluated together instead of being anchored to one noisy listing. That framing is aimed at collectors comparing distinctions such as 1st Edition versus Unlimited or PSA 8 versus PSA 9.

The launch announcement says the early version includes dozens of sets, millions of graded copies rolled up, tracked market capitalization, and daily movers spanning vintage and modern slabs. Those figures are project-provided snapshots, not independently audited measurements. The announcement also identifies examples such as Charizard, Suicune 1st Edition, Blaine’s Arcanine, Espeon Holo, Houndoom, and Misty’s Gyarados.

The timing reflects a broader move toward structured Pokémon market analytics. For comparison, TCGCharts publishes market figures based on sold listings and describes a methodology that combines population data with grade-level median prices. That does not validate PHASMA’s numbers, but it illustrates the same underlying shift: collectors increasingly want a repeatable valuation model rather than a single comparable sale.

PHASMA says the current release is an early public version and invites feedback on coverage, user experience, and which sets and grades should be added. The project also said its earlier surgical-robotics direction was paused because it lacked sufficient interest or funding, and that it later shifted toward Pokémon valuation data. The forum post describes the strategic change and the product’s on-chain potential, but it does not establish a specific blockchain architecture or a completed partnership.

The PHASMA website was not accessible to the verification tool used for this article. Readers should therefore treat the platform’s coverage, market-cap figures, and methodology as claims to inspect directly before using the service for buying or selling decisions.

Sources: Introducing PHASMA Cards; TCGCharts Press & Data.

Box::leak converts a Box<T> into a reference whose lifetime can be extended, making it useful for deliberately permanent data such as process-wide configuration or registries. The risk appears when a program treats that reference as a temporary escape hatch, later reconstructs ownership through a raw pointer, and attempts to free the allocation.

The Rust release team says this round-trip pattern can interact badly with current and future compiler optimizations, with the concern becoming more significant as custom allocators approach stabilization. Rust 1.99 therefore recommends Box::into_raw or the newly stabilized Box::into_non_null when the allocation must eventually be reclaimed. Those APIs preserve an explicit ownership transition instead of presenting the allocation as leaked for the lifetime of a reference.

For library authors, the practical review question is no longer simply “does this compile?” It is “is this allocation intentionally permanent?” Search unsafe code and FFI adapters for Box::leak, raw-pointer reconstruction, and manual deallocation. If reclamation is part of the design, use an ownership-preserving conversion and document the allocator and deallocation contract.

A caveat matters: Rust 1.99 changes the documentation recommendation, not the language semantics. Intentional leaks remain a valid design choice; the warning is aimed at patterns that leak first and reclaim later.

The key idea is to turn a prepaid balance into a private note. A user deposits funds into a vault, then produces a zero-knowledge proof showing that a valid note can cover a bounded session and has not already been spent. The server verifies the proof without learning which deposit or person funded it. A nullifier prevents double spending, while a Merkle tree lets the proof establish membership without identifying a particular note.

The implementation separates the payment path from the request path. A local client proves authorization to the zkAPI server, which issues a short-lived, spending-limited API key. In the runtime-key mode, the user’s device sends prompts directly to the provider. When the key expires, signed usage information is used to settle the actual cost rather than the reserved cap. The repository documents a stack built around Groth16 on BN254, Poseidon hashing, note-bound commitments, and a 32-level Merkle tree.

That separation is the more interesting developer primitive than the AI demo. An ICP application that calls a metered external service could, in principle, treat “permission to spend up to this amount” as a proof-bearing session capability rather than attaching every request to a durable account. The application would still need an appropriate verifier, settlement service, and key-management design; zkAPI does not provide an ICP integration, and this is an architectural inference rather than a released ICP feature.

There is an important privacy boundary. zkAPI breaks the link between payment and usage, but it does not make the request itself anonymous. The provider can still see prompts and responses, the user’s network metadata may remain visible, and timing or repeated content can correlate sessions. The Ethereum Foundation explicitly describes network anonymity and content privacy as separate layers.

For ICP developers, the practical takeaway is to model three independent questions: who is authorized to spend, what service receives the payload, and who can reconcile the bill. Zero-knowledge proofs can separate the first and third from the second, but only if the session key, usage receipt, replay protection, and recovery path are treated as protocol state. That boundary is portable; the current zkAPI deployment is not yet an ICP component.

That packaging matters for Chain Fusion because cross-chain integrations depend on more than canister code. Developers and operators also need a known version of the surrounding IC tooling and test environment. A single, named release gives teams a reproducible reference for integration tests, deployment scripts, and incident reports.

The safety lesson is to verify the artifact before treating it as infrastructure. The release page lists checksums, while ICP’s deployment guidance instructs operators to compare downloaded artifacts against their expected hashes and to stop when they do not match. The same documentation separates IC OS version election from deployment: a release tag alone does not mean that a version has been elected or deployed across the network.

The release page does not include a component-by-component changelog. Accordingly, this report does not claim that the tag introduces a new Chain Fusion protocol feature. Its defensible significance is operational: it gives builders a fresh, addressable package against which Chain Fusion tooling and test pipelines can be pinned, verified, and later reproduced.

For teams shipping cross-chain functionality, the practical checklist is straightforward: record the tag and commit, verify downloaded checksums, run integration tests against the pinned tooling, and confirm any network deployment status separately through the relevant NNS and dashboard records.

The thread was opened to collect SNS upgrade announcements in one subscribable forum topic. Its early notices identified the SNS Governance, SNS Root, and SNS Swap canisters as upgradeable. Later posts recorded proposed SNS-WASM publications with source Git hashes and Wasm hashes, giving DAO participants a concrete artifact to inspect before deciding whether their SNS should move forward.

That publishing pattern matters because an SNS upgrade is not simply a software download. The SNS framework is designed so that decentralized applications can be governed by an on-chain DAO, and the SNS codebase exposes upgrade-related concepts such as running versions, upgrade parameters, and the canisters selected for an upgrade. In practice, a release announcement becomes an input to a proposal and voting process.

DFINITY’s SNS testing repository demonstrates the same operational sequence: a dapp can be placed under SNS control, and its canister can then be upgraded through an SNS proposal. The repository also shows why voting remains part of the deployment path: a proposal can pass immediately in a single-neuron test setup, while a more distributed configuration requires additional votes.

The strongest lesson from the thread is therefore about observability. A DAO needs to know which Wasm artifact is available, which canister type it targets, and how that candidate relates to the version already running. A single aggregation point reduces the chance that upgrade information is scattered across unrelated announcements, while hashes let operators compare artifacts without relying on a human-readable version label alone.

There is an important limit to what the thread proves. It began in 2023 and functions as a historical aggregation record, not as a guarantee that every SNS is current or that every listed release remains the latest. The supplied material is also truncated, so it should not be treated as a complete upgrade ledger. Operators should independently check the current SNS-WASM upgrade path, the running SNS version, the relevant proposal, and the artifact hash before submitting or voting on an upgrade.

For ICP developers, the practical takeaway is straightforward: subscribe to the aggregation thread, treat each announcement as a release candidate rather than an automatic deployment, and connect the published hash to an explicit SNS governance decision. The value of the thread is not that it removes governance from upgrades; it makes the software evidence needed for governance easier to find.

For developers, the practical change is a build-topology decision: 32-bit Windows binaries must be produced from a supported host toolchain, such as 64-bit Windows. The Rust RFC for the MSVC target describes this as retaining std support while ending compiler-host support. The Rust project’s platform documentation also describes the Windows targets as capable of cross-compilation when the relevant C and linker toolchains are installed.

The decision reflects both platform reality and maintenance cost. The Rust announcement says general 32-bit Windows support ended in October 2025, while the project has also encountered compiler crashes in i686 MSVC builds and out-of-memory failures while building LLVM with the GNU C++ toolchain. The result is a narrower promise: Rust will preserve the ability to target 32-bit Windows, but will no longer treat 32-bit Windows as a viable environment for building the Rust toolchain itself.

That distinction matters for CI and release engineering. A pipeline that currently installs an i686 Windows host toolchain and runs rustc there will need to move compilation to a 64-bit or otherwise supported host. A pipeline that only needs the target standard library can continue using the distributed i686 target artifacts, subject to its native C toolchain and linker requirements. The MSVC target will also continue to receive CI testing, although it will no longer be tested as a compiler host.

This is a target-support change, not a removal of 32-bit Windows output. Other 32-bit platforms are not affected by the announcement. The project also does not specify the exact rustup error or migration steps for existing 32-bit Windows installations, so teams should validate their installation and release process before adopting Rust 1.100.0.

That addresses a subtle weakness in simpler designs. A proof that an input and response satisfy a relation does not, by itself, prove that the response came from the real website or from a live execution. zkPoPE moves the security target up from the TLS transport layer to the application protocol. The authors formalize the target as a UC ideal functionality and present Reclaim as a protocol intended to realize it under a deployment-aligned trust model.

The practical signal is meaningful for ICP developers building canisters or front ends that consume authenticated web facts. A useful integration should define the exact predicate—such as account status, eligibility, or a value range—bind it to the intended web service and request context, and preserve enough proof material for independent verification. Reclaim’s documentation already exposes the implementation boundary: public and private request options are separated, proofs can be verified with an SDK, and proof data can be transformed for on-chain use.

The reported benchmark is also concrete: the paper says Reclaim attested to a 1,200 kB response in 7.28 seconds on a lower-mid-range phone. That is not a claim that every ICP deployment will achieve the same result; it is evidence that large-response attestation is being measured as a systems problem rather than treated as a toy demo.

For ICP, the recommended design principle is simple: make the canister verify a narrowly scoped claim and its context, not accept a generic “this data is valid” certificate. Keep the source, request, freshness, subject binding, and verifier policy explicit. If a proof system can demonstrate only a satisfying pair, it has not yet demonstrated provenance.

Caveat: the central zkTLS paper is a September 2026 preprint, not peer-reviewed evidence of production security. Caveat: the Reclaim design depends on a deployment-aligned trust model and application credentials, so integrating it into an ICP canister does not eliminate operational trust assumptions.

Proposal 144199 proposes moving the Registry Canister to commit 98c898f. The commit combines changes that matter directly to Chain Fusion—most notably a new secp256r1 option for ECDSA chain-key configuration—with safeguards around subnet splitting, replica-version deployment, and Registry-state migration.

The cryptographic addition is deliberately incomplete on its own. The proposal allows create_subnet and update_subnet to name the NIST P-256 curve, but a subnet using that configuration still needs the key to be generated and enabled through separate proposals. For developers building cross-chain applications, that distinction matters: configuration support is not the same thing as an operationally available signing key.

The upgrade also adds a merge_subnets endpoint, exposed through a MergeSubnets proposal. Its scope is intentionally narrow: it rewrites the routing table so canister ranges move from one subnet to another, while leaving both subnet records unchanged and retaining the source subnet. That makes the operation a routing transition rather than a full subnet teardown.

Several changes are aimed at preventing control-plane races. A subnet split now fails if the relevant standard-engine replica-version record changes while fresh key material is being generated. A split from a cloud-engine subnet is also rejected while a new replica version is deploying when that subnet derives its version from the same record. Together, these checks reduce the risk that a topology change produces two subnets with inconsistent runtime versions.

The commit additionally tightens Registry invariants. Elected GuestOS and HostOS version identifiers must be parseable by the version types that consume them. Catch-up-package records must carry a CUP type, while a one-time migration classifies legacy records as Genesis or Recovery. Genesis CUPs no longer need a height field because their height is understood to be zero.

The most operationally revealing change is the increase of MAX_CHUNKABLE_ATOMIC_MUTATION_LEN from 10 MiB to 13 MiB. The accompanying commit explains that Registry migrations accumulated during a longer-than-usual upgrade cadence, producing an approximately 12 MB mainnet mutation during post_upgrade. This is a capacity adjustment for upgrade machinery, not a user-facing throughput increase—and it also exposes a maintenance lesson: deferred migrations can turn routine upgrades into atomic-state sizing problems.

The proposal was published on October 2, 2026. The related IC base release was published the same day, but the proposal itself remains the authoritative place to check the governance action and its execution state. The proposal page and source material describe the intended upgrade; this article does not independently establish that the upgrade has executed on mainnet. Likewise, adding secp256r1 support does not generate or enable a chain key: separate proposals are required for that step.

For Chain Fusion developers, the practical takeaway is to treat Registry capabilities as staged infrastructure. First verify that the relevant curve and subnet configuration are available; then verify that key generation, enablement, routing, and replica-version state have progressed consistently. The commit makes those transitions more explicit—and gives the Registry a larger buffer for the migrations needed to manage them.

The central issue is the release boundary. OpenChat preserves application state through rolling upgrades, while Canic’s current pre-1.0 policy uses reinstall-only release transitions. That makes a direct replacement of OpenChat’s existing fleet irresponsible, even if Canic can reproduce parts of its provisioning workflow.

That distinction matters because OpenChat already operates substantial infrastructure. Its indexes manage canister creation, spare capacity, cycle funding, controller checks, upgrade queues, retries, and subnet-local work. Its newer shared-user model also separates logical users from physical canisters. A generic installation loop would not automatically improve those systems.

The review identifies a narrower opportunity: Canic could eventually provide reusable infrastructure for allocation, cycle accounting, reconciliation, recovery evidence, and release provenance. OpenChat’s existing Wasm-hash governance process could remain the application’s source of authority, while Canic supplies passive artifact and deployment evidence. The forum post explicitly says that this would require preserving OpenChat’s existing guarantees, not replacing them with untested abstractions.

The technical integration surface is wider than provisioning. OpenChat uses application-owned memory managers, multiple wire formats, large payloads, reconstructed timers, and application-specific readiness logic. Canic’s runtime and observability features therefore need executable compatibility tests covering memory ownership, lifecycle ordering, codecs, argument limits, timers, uncertain replies, interrupted provisioning, and recovery.

The review proposes starting with a disposable OpenChat-shaped workload rather than production migration. That fixture would model global and subnet-local indexes, dedicated and shared user roles, group and storage roles, registration bursts, pool exhaustion, funding pressure, and lost replies. Only after those tests would scale, overhead, governance, and eventual state-preserving release support become adoption questions.

Two caveats are important. This is a source-level review, not a live-fleet census, security audit, or measured performance comparison. Canic is also pre-1.0, while OpenChat is changing its architecture, so the conclusions are provisional and do not constitute an adoption announcement.

The useful takeaway for ICP developers is a sharper ownership split: OpenChat should retain membership, routing, product semantics, and SNS-controlled release authority; Canic may eventually own physical allocation, installation, reserves, and infrastructure evidence. The hard part is proving that boundary under failure and upgrade—not drawing a larger canister topology.