> ## Documentation Index
> Fetch the complete documentation index at: https://developers.stellar.org/llms.txt
> Use this file to discover all available pages before exploring further.

# 2026-11-12

> This week Chad Ostrowski and Pam Selle of The Aha Company showed Stellar Registry, an on-chain naming and discovery system for smart contracts and their Wasms.

*November 12, 2026* · [Kaan Kacar](https://github.com/kaankacar), Developer Advocate

[YouTube video player](https://www.youtube-nocookie.com/embed/zTZtF1jL2H0?rel=0\&modestbranding=1)

## Ecosystem News

Before the guests joined, I went through some news:

* Real-world assets on Stellar are at about $5.5 billion. They crossed $5 billion around November 5.
* Chainlink Data Feeds and Data Streams are on Stellar.
* The Pyth Pro REST API works on mainnet. I tried it myself.
* With these, the ecosystem now has four, if not five, oracles.
* Curve Finance launched on Stellar mainnet. It is Curve's first native deployment outside the EVM world.
* MetaMask made Stellar a default network.
* WalletConnect Pay went live, with LOBSTR as the first wallet.
* Freighter became Varial.
* Stellar Expert opened API subscriptions.
* Protocol 30 "Bell" is live on testnet. The mainnet vote is set for November 23.

## Meet Stellar Registry

My guests were **Chad Ostrowski** and **Pam Selle** of **The Aha Company**. Chad is co-architect of Stellar Registry. He was also my guest for the Moonlight session in August ([2026-08-27](https://developers.stellar.org/meetings/2026/08/27.md)). Pam is lead engineer on Stellar Registry and leads the team. She presented the registry at Hack Meridian, and you can watch that session in the [Hack Meridian Day 1 stream](https://www.youtube.com/watch?v=avVZbiI2Cig).

**Stellar Registry** is an on-chain naming and discovery system for smart contracts. It gives contracts and their code human-readable names and versions, like a package manager. The Aha Company builds it as a Stellar public good, with quarterly public deliverables under the SCF Public Goods Award. For me, it is one of the greatest projects to come out of the Public Goods Award.

The site is at [stellar.rgstry.xyz](https://stellar.rgstry.xyz) for mainnet and [testnet.rgstry.xyz](https://testnet.rgstry.xyz) for testnet. Chad said the URL is temporary. The team will probably move to a more standard domain, and he asked for ideas.

## Contracts and Subregistries

The site lets you browse the contracts and Wasms deployed on Stellar. Chad searched for `kale`. The results showed an entry in `unverified` and entries in the `kale` namespace.

A namespace is a **subregistry**:

* **`unverified`**: anyone can publish Wasms and contracts there. This is where you publish first.
* **Your own subregistry**: Tyler van der Hoeven asked for `kale` through governance, and he has full control of it.
* **The root registry**: entries need the governance process.

A contract page lists the contract's functions. You can call them from the browser with a connected wallet, as in Stellar Lab. Chad showed this with the KALE contract (`plant`, `work`).

For cross-contract calls, add the `stellar-registry` crate. Its `import_contract!` macro gives you a fully typed client inside your contract.

Each subregistry is itself a contract, and all of them use the same `registry` Wasm. Testnet shows many versions of that Wasm.

Contracts have names only. They do not have versions. You version the Wasm.

## Wasms

Wasms have names and semantic versions. Chad's key idea: Stellar is already a module distribution system, like npm, crates.io, Python modules, Ruby gems or GitHub. You do not download the source. You reference the on-chain module, and you download the source only when you want to change it.

You can deploy from the browser: pick a published Wasm and fill in the constructor. Chad showed an OpenZeppelin fungible token ("Chad Bucks", symbol CHAD, 7 decimals, with an owner, a cap and an initial supply). He did not submit it, because no wallet was connected.

One gotcha: the UI deploys an **unnamed** contract. You see it in Stellar Expert and can call it by ID from the Stellar CLI, but it does not show in the registry's Contracts list. Named deploys from the UI are planned.

To import a Wasm, use `import_contract_client!`:

* The version is optional. Without one, the macro uses the latest version.
* It pulls the Wasm from the chain by hash and sets up the usual Soroban SDK cross-contract client.
* You can use it only for the types, without a contract ID.

`import_contract!` still works when the Wasm of a registered contract is not in the registry. It finds the Wasm by hash.

## The Registry CLI

The site is for reading. The CLI is for writing. Install the `stellar-registry-cli` crate:

```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
cargo binstall --locked stellar-registry-cli
# or
cargo install --locked stellar-registry-cli
```

Chad's tip: use `cargo binstall`. It downloads prebuilt binaries and takes about a second. `cargo install` is slow, because the registry CLI embeds the Stellar CLI. The same is true for the Stellar Scaffold CLI, which The Aha Company also maintains.

It installs as a Stellar CLI plugin, `stellar registry`. The commands Chad showed:

* `stellar registry publish`: uploads a Wasm and registers it in one step (`--wasm`, `--author`, `--wasm-name`, `--binver`).
* `stellar registry publish-hash`: registers a Wasm that is already on chain.
* `stellar registry deploy`: deploys a new contract from a registered Wasm and gives it a name.
* `stellar registry register-contract`: gives a name to a contract that is already deployed.

The biggest gotcha: add the `unverified/` prefix to the name, for example `unverified/hello-world`. Without the prefix, the CLI targets the root registry, and that needs governance.

Versions follow semantic versioning. After you publish `0.1.0`, you cannot publish `0.0.1`. And why the verb "publish"? When you upload a Wasm, you publish a library for other people to use.

Chad expects `publish-hash` and `register-contract` to go away as separate commands, since the main commands can wrap them. This is on the backlog.

## Governance

Governance removes the `unverified` prefix. The Governance tab has three forms: add a contract to the root registry, add a Wasm to the root registry, and create a new subregistry.

* **Testnet**: the form creates a Tansu DAO proposal. An approved proposal calls the registry contract with the given parameters.
* **Mainnet**: the form opens a GitHub issue in [`stellar-registry/gov`](https://github.com/stellar-registry/gov), and a maintainer reviews it.

The team tests the Tansu process on testnet before it moves mainnet to Tansu.

## Publishing From GitHub Actions

Chad compared the `registry` Wasm versions on testnet with the releases of [`stellar-registry/contracts`](https://github.com/stellar-registry/contracts). They match (0.8.0, 0.7.0, 0.6.x). A GitHub Action publishes these Wasms on testnet, and no person runs the CLI.

[`stellar-registry/actions`](https://github.com/stellar-registry/actions) has reusable workflows that you combine. `registry-publish` uploads the Wasm and names it in the registry.

The author is a smart account (a C address), and its secret key is a GitHub secret. Why is this safe? The smart account has a policy: the key can only call `publish` on the registry contract. Chad said the team built a policy language for smart accounts. The same policy engine powers Nido, their passkey wallet.

The workflows also make attested builds (SEP-55). Stellar Expert does not run its verification pipeline at the moment, so the attestations do not show there yet. Chad admitted the actions README needs work.

## Roadmap

[`stellar-registry/roadmap`](https://github.com/stellar-registry/roadmap) is a fork of the SCF Public Goods repo, and it tracks the quarterly deliverables. The 2026 Q4 items Chad named:

* **Account names**: named G addresses, and named C addresses as smart accounts. The UI will show a name instead of an author address like `CBHP...`.
* A simpler `import_contract!`.
* UI improvements.
* More work on `stellar-registry/actions`.

Pam added in the chat that account names already work at the contract level and in the API. The UI comes next.

## Q\&A With Pam and Chad

* **Why would I use it?** Pam: you get human-readable names for your own contracts, backed by on-chain data. Other people, and agents, can find and use your contracts by name, so you do not pass C addresses around. It is all open source, and you can deploy your own registry contract if you want full control.
* **About Pam.** She has been lead engineer on the registry for about five months. This was her first Stellar Developers Meeting.
* **How do contract upgrades work?** Pam: a contract is like an address book entry that points at a Wasm. An upgrade changes the Wasm it points to. Publish the new Wasm version to the registry, then call your contract's upgrade function as usual. The registry indexer watches the network, so the UI shows the change at indexing speed. Chad added that the actions do not upgrade contracts yet; they only publish the new Wasm. An upgrade step makes sense on testnet. The registry contract itself upgrades only through governance. Pam wants feedback here, so open an issue on the actions repo with your use case.
* **Anything other than GitHub Actions?** One team member is a fan of Radicle. Pam: the actions only wrap the registry CLI and the Stellar CLI, so you can do the same in other CI systems. Ask the team.
* **What does it cost on mainnet?** Chad: publishing every intermediate Wasm version makes sense on testnet only. A Wasm upload on mainnet is an expensive transaction. For mainnet, keep a human in the loop and start the action by hand. You can set which network an action runs on.
* **What about unverified contracts?** I compared this with the community skills on [skills.stellar.org](https://skills.stellar.org). Chad: the only warning is the `unverified` prefix. Someone can publish a contract named USDC in `unverified`, and it may not be legit. For the root registry, the request must say who you are and why the team should trust you, and the team checks before it adds the entry.
* **What about long-term maintenance?** Chad: Public Goods Awards for now, and the team wants to keep full-time staff on it. Pam: everything is open source and on chain. If the team stops, the data stays, and someone can redeploy. Charging for the registry is not on the roadmap. Pam also said the audited OpenZeppelin Wasms are already uploaded, so you can deploy from them without paying the upload fee again.
* **Can a subregistry allowlist G accounts for verification?** Chad: a subregistry may fit. Its owner decides what gets in and can set a different governance process. An unmanaged subregistry is possible, but Chad sees a risk: its name can look more legit than `unverified`. A subregistry on the main registry still goes through governance.
* **Nido questions?** Out of scope for this call. The Hack Meridian talk has a Nido section, and Nido has a Telegram group.
* **What if the indexer goes down?** Chad: the UI stops updating, and a new publish may not show at once. The data is on chain.

Pam runs monthly Stellar Registry office hours. The next session is the week after the call. RSVP on [Luma](https://luma.com/kzhl15rc).

## Closing

About 210 of you watched live. Thank you, Chad and Pam. If you have more questions about Stellar Registry, Nido or The Aha Company, go to the office hours, or find the team on the Stellar Developers Discord.

If you want more from The Aha Company, see [2026-08-27](https://developers.stellar.org/meetings/2026/08/27.md) on Moonlight with Chad. Last week's meeting was [2026-11-05](https://developers.stellar.org/meetings/2026/11/05.md) with Koul. See you next week at the Stellar Developers Meeting.