🌸 Astroflora

A wasm registry where a build can prove where it came from.

Astroflora is an ICRC-118 registry of canister types and their versions for the Internet Computer, with orchestrated upgrades that anyone can veto before they land. What makes it different is one badge: built on-chain.

Browse the registry Publish a wasm

RegistryNamespaced canister types, versioned wasms, upgrade paths, deprecations. ICRC-118.
VerificationAttestations and divergence reports on every wasm. ICRC-126.
OrchestrationUpgrades performed by a canister, from the registry, with snapshots. ICRC-120.
VetoA published waiting period in which any stakeholder can stop an upgrade. ICRC-137.

What "built on-chain" means, and why one endorsement is enough

Most registries can only tell you what someone uploaded. Astroflora can tell you what was compiled. The moxzi compiler runs as a canister on the Internet Computer. When you build with moxzi build --remote, that canister compiles your source, links the result, and records the sha256 of the exact bytes it produced, together with a digest of the sources and the options it was given.

When a wasm is published, the registry asks the compiler canister a single question, keyed by that hash: did you build these bytes? If the answer names a build, the registry files the compiler's attestation and the wasm reads verified. If the compiler has never seen those bytes, nothing is filed and the wasm stays unverified. Change one byte of a verified wasm and the answer is a definite no.

That is why a single endorsement suffices here where it would not elsewhere: the endorser is a canister, not a person. Its build records are public state, its answer is a query anyone can repeat, and its own code is in this registry. You do not have to trust the badge. You can ask the same question yourself.

Anyone may also file an attestation or a divergence report. Those are recorded as what they are: one voice, or one open dispute. An unresolved divergence report outranks every attestation, including the compiler's.

How to publish

Publishing is open. You need two things first: a namespace, and room to store bytes.

  1. Claim your domain. Namespaces are reverse-DNS (com.example.myapp). Claim example.com at the ICRC-86 domain registry, prove it with a TXT record at _icrc86.example.com, and every namespace under it is yours to publish in. 5 XDR in ICP, once.
  2. Buy storage. 30 XDR in ICP buys 70 MB of registry storage for three years, pro rata for any amount. Both steps are on the registry's Publishing access page.
  3. Build and publish.
moxzi build --remote src/Main.mo --canister xcn6l-iqaaa-aaaai-raq6q-cai
moxzi publish out/Main.wasm --registry l55bi-3aaaa-aaaai-atk4a-cai \
      --namespace com.example.myapp --version 1.0.0 --canister xcn6l-iqaaa-aaaai-raq6q-cai

The publish step uploads the bytes, then asks the registry to pull the compiler's attestation and prints what it says: verified, unverified, or DIVERGENT. A wasm built locally publishes fine; it is simply unverified, and the registry says so instead of saying nothing.

Upgrades you can stop

Canisters that opt in are upgraded by an orchestrator canister (ICRC-120) that installs versions straight from the registry, taking a snapshot first. Before an upgrade runs, it sits in a published waiting period (ICRC-137) in which any stakeholder can veto it. The veto canister, the orchestrator, and the registry are themselves published in the registry, so the machinery that upgrades your code is held to the same standard as your code.

Standards

ICRC-118 wasm registry · ICRC-120 orchestration · ICRC-126 verification · ICRC-137 veto · ICRC-86 domain claims