Your first on-chain buildalpha

Run moxzi build --remote, choose the identity that pays, and read what it prints.

This page runs a build on the production compiler canister. It costs cycles, paid in ICP, when the canister has payment turned on.

Run the build#

moxzi build hello.mo --remote https://icp-api.io --canister xcn6l-iqaaa-aaaai-raq6q-cai

The command runs until the build finishes: a few minutes for a small program. It uploads the source files (the same ones moxzi deps hello.mo lists), starts a job, drives it step by step, and writes hello.wasm and hello.did.

When payment is on, it shows the price and asks before spending:

remote: this build escrows 0.3501 ICP (rate 35000 XDR-permyriad/ICP); settlement charges 3x actual use and refunds the rest
remote: your balance is 2.0000 ICP
proceed? [y/N] y
remote: approved 0.3502 ICP
remote: escrow pulled, job 0
…
remote: settled: charged 0.0009 ICP, refunded 0.3489 ICP

The escrow is a maximum. You're charged for what the build used, and the rest is refunded. See Payment.

Options#

If the command is interrupted (a network error, a laptop going to sleep), the job waits in the canister. Continue it with --resume-job; moxzi verify --list shows recent job ids.

The identity that pays#

The canister records who owns each job and charges that identity. By default moxzi uses its own key, created on first use:

moxzi: new build identity at ~/Library/Application Support/moxzi/identity.key

It prints the principal when it connects. Send ICP to that principal to pay for builds. Set MOXZI_IDENTITY to keep the key somewhere else.

To use a key you already have:

dfx and icp can keep keys in the system keyring, where other programs can't read them. In that case, export the key to a file and pass it with --pem:

icp identity export alice > alice.pem
moxzi build hello.mo --remote https://icp-api.io --canister xcn6l-iqaaa-aaaai-raq6q-cai --pem alice.pem
rm alice.pem

Your dfx or icp identity usually controls your canisters. moxzi's own key only holds the ICP you send it, which limits what's at risk if something goes wrong. Prefer it unless you have a reason not to.

Troubleshooting#

Next steps#

• Verifying a build.
• Publishing to a registry.