PG Award Proposal: Stellar Registry

[github-actions]

Stellar Registry

Stellar Registry is an on-chain smart contract registry for Soroban that lets developers publish,
version, discover, and deploy Wasm binaries and contract instances, making contracts reusable across
the ecosystem like packages.

Category	Developer Experience
Website	https://rgstry.xyz
Repository	https://github.com/theahaco/scaffold-stellar/tree/main/contracts/registry
First Released	March 2026
Intake	#23
Budget Requested	50000

Project Description

Registry is the missing infrastructure layer between "I wrote a smart contract" and "the ecosystem
can safely use my smart contract."

Registry tracks two things:

1. Contracts: Registry gives contracts human-friendly names, rather than gobbledigook IDs, as
   well as tracking a contract's owner and its Wasm.
2. Wasms: Stellar separates a contract instance, if you will (see item 1), from the WebAssembly
   (Wasm) binary that defines its behavior. Many contracts can use the same Wasm binary, but today
   that's impractical because Wasms are identified only by a gobbledigook ID.

Registry makes these usable. It gives them both names and versions, making the development
experience feel like familiar package management—like crates.io or NPM.

Team & Experience

Scaffold Stellar is built and maintained by The Aha Company (formerly Aha Labs), a team of 10+
senior engineers deeply embedded in the Stellar ecosystem.

Early Soroban origin:

In 2022 (before Soroban had a name) SDF already had a clear ambition: launch their upcoming smart
contract platform with a “batteries-included” developer experience. The gap was execution capacity:
there was no in-house team available to design and implement the developer workflows needed to make
that promise real. Tyler van der Hoeven went to major blockchain conferences to find the right team,
and identified The Aha Company as the team with the right combination of product mindset and deep
technical ability to “install the batteries.”

Foundational Stellar developer workflows we designed and shipped:

We envisioned, architected, and implemented several of the workflows that have become core to Soroban
development on Stellar, including:

• Stellar CLI smart contract workflows, such as the contract invoke behavior and associated
  developer ergonomics that leapfrog, rather than ape, other blockchain ecosystems, simplifying
  testing, deployment, and interaction.
• JavaScript developer experience patterns, including the Contract Client behavior in
  stellar-sdk-js, which helps application developers interact with contracts more safely and
  predictably.

Why we were selected for Scaffold Stellar and our SCF track record:

In early 2025, SDF searched for a team that could bring a ScaffoldETH-like end-to-end experience to
Stellar. They selected us based on:

1. our deep CLI & JS expertise proven through shipped core tooling, and
2. our track record delivering developer infrastructure via SCF, including:
   • Smart Deploy:
     https://communityfund.stellar.org/project/smart-deploy-yoj
   • Loam:
     https://communityfund.stellar.org/project/loam-qj5

Scaffold Stellar is a direct continuation of that work: turning the hard-won Developer Experience
(DevX) knowledge from core tooling into a “front door” experience that helps developers go from idea
to proof-of-concept quickly, with strong defaults and a convention-over-configuration approach.

Ongoing maintenance and production-grade integration experience:

Since then, we have remained engaged with SDF to support and maintain key tooling (most recently
improving Stellar CLI handling of hardware-based keys) and we continue to operate as an
integration partner on production deployments. Notably, we architected and developed Société
Générale’s EURCV on Stellar (now live), bringing a rigorous, real-world perspective to developer
tooling and reliability requirements.

Deep community participation and ecosystem leadership:

Our team includes well-known ecosystem contributors. Several members hold key community roles (e.g.,
SCF Pilot, category delegates) and actively build their own SCF projects (e.g., Moonlight,
Tansu, Stellar Merch Store, PG Atlas). We contribute to protocol and tooling discussions, provide
developer support at hackathons and conferences, and invest heavily in community outreach and
education. We show up consistently at major events and actively communicate about Stellar, both its
strengths and the practical realities builders need to know.

Cross-ecosystem perspective (DevX benchmarking):

Beyond Stellar, The Aha Company is also an integration partner in other ecosystems (e.g., Filecoin,
XRPL, Cardano, Canton, Starknet). This gives us a unique ability to benchmark developer experience
across chains and bring proven patterns back to Stellar—while keeping Scaffold Stellar aligned with
what developers expect from modern, full-stack tooling.

Retroactive Impact

Stellar Registry launched within the last three months on Testnet, and has already garnered
significant interest from ecosystem partners/projects such as PG Atlas and the SDF DevRel team for
their Mexico City hackathon.

Past Deliverables

N/A — this section intentionally left blank — please pass validation; you told me to put "N/A" and
that's just what I did but now validation won't pass. Maybe I need to put more words?

Proposed Impact

Make the Registry production-ready. Deploying to mainnet (theahaco/scaffold-stellar#433)
transforms the Registry from a testnet experiment into permanent Stellar infrastructure — a shared,
on-chain contract store that any Soroban developer or dApp can publish to and consume from.

Make contract composability ergonomic. The import_contract! macro
(theahaco/scaffold-stellar#419) and its build-time safety enforcement (theahaco/scaffold-stellar#452)
mean that any Soroban developer can depend on Registry contracts the way they depend on Rust crates —
with a clean API and compile-time guarantees that flagged or compromised contracts won't ship.

Make the Registry discoverable and usable without the CLI. Through search, pagination, UI
enhancements, verified build integration, and human-readable addresses
(theahaco/scaffold-stellar#454, theahaco/scaffold-stellar#453, theahaco/scaffold-stellar#455,
theahaco/scaffold-stellar#421), rgstry.xyz becomes a real contract discovery platform — not just a
read-only dashboard — so developers can find, evaluate, and deploy contracts directly from the
browser.

Lower the barrier to entry. Targeted Registry documentation (theahaco/scaffold-stellar#426),
cross-linked with Scaffold Stellar's docs, ensures developers arriving from any direction — the CLI,
the web explorer, or Scaffold Stellar — can get productive with the Registry quickly.

Benefit to the Stellar ecosystem: The Registry is ecosystem infrastructure, not a product
feature. Every Soroban project benefits from a trustworthy, searchable, mainnet-deployed contract
store. It enables contract reuse, reduces duplicated effort across teams, and raises the baseline
security and auditability of the ecosystem. Scaffold Stellar remains the recommended starting point
for building on top of the Registry, but the Registry stands independently and is designed to serve
the entire Soroban developer community.

Proposed Deliverables

D1: Mainnet Deploy of Stellar Registry (theahaco/scaffold-stellar#433)

Deploy the Registry smart contract to Stellar mainnet and confirm it is publicly accessible via
stellar registry CLI and rgstry.xyz.

Measure: the contract is deployed & the CLI points to it.

D2: import_contract! Macro (theahaco/scaffold-stellar#419)

Publish a working import_contract! macro in the stellar-registry crate that allows cross-contract
client instantiation with a single line of Rust.

Measure: the macro is available in a released crate version, documented with at least one working
example, and covered by integration tests.

D3: Flagged Contract Enforcement at Build Time (theahaco/scaffold-stellar#452)

Extend import_contract! and import_contract_client! to emit a compile-time error when the
referenced Wasm or Contract is flagged in the Registry.

Measure: a test exists that demonstrates a flagged contract causes a build failure, and the behavior
is documented.

D4: Server-Side Search, Pagination & Sorting on rgstry.xyz (theahaco/scaffold-stellar#454)

Replace the current client-side full-data-fetch approach with API-backed search, pagination, and
sorting on rgstry.xyz.

Measure: the explorer handles at least 1,000 published Wasms/Contracts without degraded load time,
search returns results server-side, and pages load incrementally.

D5: rgstry.xyz UI Enhancements (theahaco/scaffold-stellar#453)

Ship three specific improvements to the Registry web explorer:

1. Contract Explorer embedded on contract detail pages
2. stellar contract info meta metadata surfaced on Wasm and Contract detail pages
3. A "deploy this Wasm" button that initiates a Registry deploy from the UI

Measure: all three features are live on the production rgstry.xyz site and manually verified
against at least one mainnet contract.

D6: Verified Build Integration with Stellar Expert (theahaco/scaffold-stellar#455)

Display verified build status from Stellar Expert's API on Registry Wasm and Contract detail pages.

Measure: the verified build badge or indicator is visible on at least one Wasm detail page with a
known verified contract, and the integration is live in production on rgstry.xyz.

D7: Registry Documentation & Education (theahaco/scaffold-stellar#426)

Publish complete Registry documentation and videos covering:

• publishing a Wasm
• deploying a named contract
• using import_contract!
• deploying an unnamed contract
• publishing/releasing using CI workflow
• more!

Measure: documentation is live on Registry's own docs site & The Aha Company's YouTube channel.

Legal Acknowledgements

• As the project representative, I agree to the Legal Acknowledgements.

[orbitlens]

The Stellar Registry (this submission) is heavily integrated (and crosslinked) with the Scaffold Stellar proposal. It uses the same GitHub repo. The registry has been listed in the Retroactive Impact section ("- Shipped Testnet Registry frontend") of that proposal. Looks to me like an integral part of the Scaffold Stellar service rather than a standalone service.

Is there any specific reason why this is posted separate from the original proposal? If that's solely the money question, I'd proposed to make an exemption and increase the funding of the Scaffold Stellar proposal instead of tracking two services separately if possible (not sure if that interferes with the SDF mandate).

[zachfedor]

The original idea for Registry was spawned by a visible need in the ecosystem that was made more evident during work for Scaffold. It has since spun off into it's own service, and while they are complimentary and make use of each other's work, we think they are separate enough to provide value in and of themselves.

As for repositories, the form validation prevents us from adding multiple links so I'll add a few more repos here for you:

• Registry UI: frontend application for browsing published Wasms/Contracts currently launched for testnet at https://testnet.rgstry.xyz/
• Registry Indexer: indexer tracking activity on the contract and serving data to each frontend (testnet and mainnet)
• Registry CLI: Stellar plugin CLI for managing contract deployments on the Registry
• Registry macros: Rust macros that handle cross-contract calls via the Registry

The Registry contract that was linked in this form is the layer that links these pieces together and we thought that would be the best entry point into discovering Registry's capabilities.

If you would prefer bundling the proposals and milestone tracking of both projects, we can accommodate that though.

[aolieman]

Looks to me like an integral part of the Scaffold Stellar service rather than a standalone service.

It certainly used to be!

Only speaking as a (potential) user right now: I was actually happy to hear from Chad that Registry had spun off from Scaffold Stellar. I've tried out Scaffold at hackathons and I have not yet become scaffold-pilled. It's cool and I can see the value prop, but it's not for me. Registry has properties that I was actually missing in the ecosystem. I will be a Registry user. So for me personally, it's quite nice not to have to make funding recommendations on them as a bundle, even if they are built by overlapping teams and are heavily integrated already.

(Disclaimer: I have not yet had a close look at the Q2 deliverables of either project.)

[alejomendoza]

This is a super valuable project for the ecosystem. I strongly agree with @orbitlens that the Registry should stand independently from the Scaffold framework to serve as a foundational public good for all Soroban protocols.

Regarding the verification flow, I have a few questions/suggestions on the architectural direction:

The Audit Bank Model: Rather than the Registry itself managing 'verified' status, what are your thoughts on integrating an 'Audit Bank' contract? Ideally, this would be a separate Mainnet contract where authorized audit firms sign off on specific WASM hashes. The Registry could then simply reference these signatures.

Cross-Contract Verification API: For high-stakes protocols that need to verify AMM or bridge hashes in the 'hot path' (e.g., inside a transfer hook), will the Registry expose an infallible is_verified(wasm_hash: BytesN<32>) function? Understanding the gas profile of this cross-contract call is critical for those of us designing sovereign token physics.

Publisher Identity & Impersonation: Will the Registry allow protocols to programmatically verify the Publisher’s Address? It’s essential to distinguish between a hash named 'Aqua' published by the Aqua team versus one published by a third party.

Governance of Flags: Regarding the 'Flagged Contract' feature (D3), what is the proposed governance model for flagging? If a protocol depends on a hash that is subsequently flagged, how is that reflected on-chain for contracts performing runtime checks?

Immutability of Mappings: Once a WASM hash is associated with a specific name/version string, is that mapping immutable, or is there a path for an admin to update the hash for an existing version?

Integrating a standalone Audit Bank contract would essentially turn this into a trustless 'Web of Trust' for Stellar. Excited to see how this develops!

[zachfedor]

Thanks @alejomendoza!

Integrating with the Audit Bank is a great idea. We can definitely track in an issue for further discussion, but it seems a little out of scope right now. If it's simply a check on a Wasm version saying it was audited, or even a reference to those signatures, does that actually provide much value? What was the result of the audit, good or bad? And since there's no standardized deliverable from the audit firms, it's hard to parse for any data. That seems more like a task for the Audit Bank than Registry.

Publisher Identity is handled by verification from the Security Council and there are multiple "channels" of the Registry on a single network. Verified contracts/Wasms are published on a main channel, but anyone can publish on the unverified channel and you assume the risk of using those contracts.

I'll let @willemneal chime in for the rest.

[willemneal]

@alejomendoza To add to audit bank, currently we are curating the contracts in the main registry. However, this could be a good idea for the unverified registry. It could be one way for contracts to migrate.

Currently publishing is immutable. We don't even allow yanking. And all versions must be greater than the previous. We could add the ability to have the admins change the hash, but have no plans currently. It would be easy to add in an update though.

Cross-Contract Verification API: For high-stakes protocols that need to verify AMM or bridge hashes in the 'hot path' (e.g., inside a transfer hook), will the Registry expose an infallible is_verified(wasm_hash: BytesN<32>) function? Understanding the gas profile of this cross-contract call is critical for those of us designing sovereign token physics.

In this case, I would imagine that you would want the contract you are calling to be verified not the hash. Ideally contracts would upgrade/deploy via the registry ensuring that their associated wasm hash is verified.

Currently when Wasms are published via the contract their hash's are stored in a set to ensure they are only published once. Also we allow publishing passing the wasm directly, e.i. you do not have to upload and subsequently publish the hash. We haven't made full use of this and given the increase in transaction limits we for sure can inspect custom sections and check signatures, etc. Either way we currently don't expose this Wasm hash set, but that could serve as the is_verified check since all the root contracts are verified. However, this would only work now for the root contract.

As for the cross-contract verification API, our current proxy method allows you to call a contract via it's name. This is acts as a way to ensure it is the expected contract.

Governance of Flags: Regarding the 'Flagged Contract' feature (D3), what is the proposed governance model for flagging? If a protocol depends on a hash that is subsequently flagged, how is that reflected on-chain for contracts performing runtime checks?

Currently it is a contract that is flagged rather than a Wasm. However, I could imagine wanting to flag all contracts which instantiate a flagged Wasm. As for the governance it will be the same model for adding contracts and Wasm publishing to the root registry.

Publisher Identity & Impersonation: Will the Registry allow protocols to programmatically verify the Publisher’s Address? It’s essential to distinguish between a hash named 'Aqua' published by the Aqua team versus one published by a third party.

Currently we allow for nested registries. This means initially the governance model will approve a aqua registry, allowing them to have their own namespace. So when importing the contracts/wasms users can trust aqua/<..> will resolve correctly. And if someone in the unverified registry tried to impersonate it would be unverified/aqua/<...>; also currently registry resolution is only one layer deep.