i want to see the source codes when i deploy my canisters
Short version: the IC doesn’t store source code, only the compiled WASM module. So “seeing the source” isn’t something the protocol gives you, it has to be opted into by the deployer.
What you can get from any deployed canister today:
- Module hash via
read_stateat/canister/<id>/module_hash, certified. - Candid interface if the deployer included
candid:serviceas a custom WASM section (most tools do this by default). - Anything else the deployer put in custom sections (
icp:public <name>is readable by anyone,icp:private <name>only by controllers). Bounded by the 2 MiB certified-read response cap.
What’s missing: there’s no protocol-level field for “source repo” or “source code.” The WASM is on-chain; the .rs / .mo files are not.
The patterns people use to bridge this:
- Embed a pointer: a small public custom section with repo URL + commit hash + build command. Cheap and certified, but you’re trusting the deployer’s claim.
- Reproducible builds: publish source externally, anyone rebuilds, compares the resulting module hash to the on-chain one. This is the only approach that’s actually verifiable end-to-end. The hard part is making the build deterministic (pinned toolchain, no embedded timestamps, etc.).
- Verification services / registries: a third party rebuilds from claimed source and publishes an attestation. Shifts trust from deployer to verifier.
If you want this for your own canisters, the practical move is (1) + (2): embed {repo, commit} in a public custom section, and set up a reproducible build so anyone can verify the deployed hash matches. That’s about as close to “source visible on deploy” as the platform currently allows.
i see. so one can choose to not open source. is there a good reason to not open source or delay the open source? on icp i mean.
As long as you don’t open source, you can not verify the canister module hash, so in general you should always open source IMO.
But I guess some people want to protect their IP by not disclosing the source code. Another reason might be: security by obscurity. It is harder to break something you can not see.
I wonder if anyone has played around with Starlark as a scripting language within a runtime hosted by a canister.
Starlark maps very naturally to the same class of problem as consensus-based compute (but as a script rather than compiled). Deterministic source code, stored as text, evaluated by a trusted host runtime, with a deliberately limited capability surface.
If nobody’s tried this out on the IC before I think its worth a stab.
We can decompile Wasm and combine static analysis, formal checks, and AI-assisted semantic recovery.
This could become a practical source-less verification layer for ICP canisters.

