Register a program or an app

• lezreg, built from source (Install), with the RISC Zero executor r0vm on your PATH. Every write is simulated locally first, so writes need it at run time; reads don’t.
• Your program: a git checkout with its guest and its Cargo.lock. It can be deployed already, or lezreg deploys it in the same transaction that registers it.
• Its IDL, the interface file under idl/. It goes to your Logos Storage node; lezreg storage up starts one if you don’t run one.
• A public repository and a commit on a remote branch, so others can fetch and rebuild exactly what you registered.
• A funded account in the LEZ wallet built into lezreg, to sign as author and pay the fees. Run any write with --dry-run first: it prints the fee reserve and sends nothing. Unless the wallet password variable is set, a new wallet is created unencrypted: run lezreg wallet set-password before it holds a program’s header key, and use a separate account as author.
• Docker, to run the reproducible build yourself (lezreg build, lezreg verify).

cd my-program                       # a git checkout with a risc0 guest and its Cargo.lock
lezreg init --detect --author <YOUR_ACCOUNT>   # writes lezreg.toml; commit it
lezreg doctor                       # sequencer, registry, Storage node, r0vm, wallet, Docker, clock
lezreg publish --elf <program .bin or guest ELF> [--dry-run]

init --detect reads the name, version, description, IDL, repository and build settings from your project. publish then does whatever the chain still needs:

• Nothing deployed yet: it uploads the IDL, writes the program, and deploys and registers it in one transaction (this needs --elf).
• Deployed but not registered: it registers it. Your wallet must hold the program’s header key.
• Registered, but lezreg.toml or the tree says something new: it updates just the fields that changed.
• Nothing changed: it sends nothing.

So a release is: bump version in lezreg.toml, commit, lezreg publish. For a program you deployed earlier, lezreg adopt <PROGRAM_ID> registers it from the same file.

Deployer entry or community entry

An entry written with the program’s header key, the key that deploys and upgrades it, is the deployer entry, and there is one per program. Anyone can also publish a community entry about someone else’s program; it is kept separately and never takes the deployer entry’s place.

lezreg register --third-party --program <PROGRAM_ID> --publisher <Q> --name … …

Updating

lezreg update <PROGRAM_ID> --version 1.1.0 --idl-cid z… --idl-file …   # the author signs
lezreg update <PROGRAM_ID> --image-id <hex>                             # claim a new image after an upgrade
lezreg transfer <PROGRAM_ID> --to <NEW_AUTHOR>                          # both sign, in one transaction
lezreg freeze <PROGRAM_ID>                                              # irreversible

Only the entry’s author can update it, and every update writes a release snapshot that can’t be changed later. Programs are upgradeable by default (--immutable turns that off); after an upgrade the entry shows as stale until its author claims the new image. A transfer hands over the entry, not the header key.

From CI

The GitHub Action checks the build on pull requests and, on a tag, prepares a release you then publish from your own machine with lezreg publish --from-release. Header and author keys never enter CI: the Action has no key input and sends nothing.

- uses: jefdiesel/lez-program-registry/action@main
  with:
    mode: ${{ startsWith(github.ref, 'refs/tags/') && 'prepare' || 'verify' }}

Your entry records how to rebuild the program byte for byte: the repository and commit, the builder image pinned by digest, the risc0-build and Rust versions, the Cargo.lock hash, the manifest path, the binary name and its features. lezreg init --detect fills these in, and publish reads the commit and the Cargo.lock hash when it runs. Build information without a Cargo.lock hash is shown as UNVERIFIED. The source itself is fetched from your repository at that commit, so keep it public: if it is deleted, nobody can rebuild.

lezreg build . --binary my_guest                    # the canonical image id before you deploy
lezreg verify <program> [--mark]                    # rebuild in Docker, compile offline: Match / MatchStale / Mismatch

Anyone can run lezreg verify on your program. It rebuilds the recorded source in Docker with the network off for the compile and compares the result with the image your entry claims and the one that is live. With --mark, a match marks the program verified on that machine, and the Basecamp module’s program_label reports the mark there.

A Basecamp app is checked against the LNS name that publishes it. Say you hold alice and publish the module alice_ui:

1. Name yourself in the package

   Put "author": "lns:alice" in the module’s metadata.json. It is carried into manifest.json and covered by the package’s root hash, so it can’t be changed without changing the hash.

2. Make the record

   lezreg app record prints the app.alice_ui text entry for your name. With --upload it also puts the package on your Logos Storage node and records its CID; keep that node online, or pin the package elsewhere, so others can fetch it.

3. Sign it with your name

   Run the printed names set-text line with the LNS command line (logos-names). You sign the change as the name’s holder, and that is what vouches for the package.

4. Check it

   lezreg app verify on the package should say verified. Commands that read names need the LNS program id: pass --lns or set LEZREG_LNS.

lezreg app record alice_ui-1.2.0.lgx --upload \
    --catalog https://raw.githubusercontent.com/<you>/<catalog>/main/logos-repo.json \
    --program <program id the app calls> --keep <previous root>
#   names set-text alice app.alice_ui '{"v":1,"root":"…","sha256":"…","cid":"zDvZ…",…}'

lezreg app verify alice_ui-1.2.0.lgx

The key app.<module> is at most 32 bytes, so module names up to 28 bytes, and the value at most 512 bytes of JSON. A new release changes root in the same update that publishes it; --keep lets the name go on vouching for up to three older roots while installs upgrade. The records stay in your name’s sealed profile: only someone who knows the name can find them.

• What the registry is
• README: publish your program
• docs/APPS.md