Conversation
for more information, see https://pre-commit.ci
Co-authored-by: Chad Ostrowski <221614+chadoh@users.noreply.github.com> Signed-off-by: Pamphile Roy <23188539+tupui@users.noreply.github.com>
for more information, see https://pre-commit.ci
aolieman
left a comment
aolieman
left a comment
There was a problem hiding this comment.
Ecosystem impact checks out! Is there any way to quantify adoption? For example, a GitHub code search which reveals the projects that have used Scaffold, or Registry data as a proxy for the dApps that have relied on Scaffold for their contracts?
My general feedback is that I'd like to see a clearer breakdown of how the proposed deliverables lead to this maximum budget request. Now that Registry has spun off, it's not as clear to me why Scaffold needs to be fully staffed in Q2. I also want Aha to dedicate more time to Registry — which is perhaps contrary to what SDF would like to see.
I can tell that Q2 deliverables D1 and D8 are major refactors. For D2-D7 it's harder for me to estimate the amount of work required.
|
|
||
| ## D3: BYOFrontend | ||
|
|
||
| - Create two new Aha-maintained Scaffold frontend plugins: 1. no frontend, 2. Svelte. In addition, |
There was a problem hiding this comment.
Add 3. Effect? I hope @waldmatias can pitch this; I only have a hunch of how valuable this would be.
There was a problem hiding this comment.
We were going off the most recent State of JS survey trying to make our own little tier list based on a mix of the usage and positivity stats plus GitHub stars. Effect isn't on the list. Maybe that will change for this year's survey, but anecdotally I don't hear many folks talking about it.
There was a problem hiding this comment.
I really have to defer to @waldmatias on this. I don't do that much frontend work myself. My poorly informed impression is that Effect has particular advantages for interacting with contracts/RPC.
| Extensively researched and built with Goldsky to build Stellar Registry UI, and determined this | ||
| offering is both too immature to build as a Scaffold Stellar Extension for now, as well as being too | ||
| much of an edge case for how the extension system ended up working. We now have prior art to use to | ||
| implement a Goldsky extension later, which is being tracked in | ||
| https://github.com/theahaco/scaffold-stellar/issues/164 |
There was a problem hiding this comment.
It's hard for me to judge how well this does or does not fit into the extension system. It's clear that there is demand for help with indexer integration. Custom indexer integration is a lot of work.
Goldsky should not even be looked into imo. They are not active enough to provide good support for Stellar and to stay on top of Soroban SDK and protocol upgrades.
Mercury has rebooted, and with that, their Retroshades again is an attractive solution for within-contract indexer config.
I feel strongly about adding Obsrvr Flow to complete the batteries-included experience that Scaffold aims to offer. It is extremely performant, low hassle, and completely on top of Stellar protocol evolution.
|
@aolieman Thanks for the feedback. Speaking toward the level of effort required, D2 and D3 both require some foundational work to turn the But the real effort is less obvious. First, Scaffold's frontend is built with Stellar Design System and our Contract Explorer, both of which are React only. Second, every new package manager or framework supported supported by Scaffold will exponentially grow the amount of tests to cover all the combinations. D4 through D7 are smaller deliverables for sure, although D6 will require some testing and CI work with a fair amount of back and forth with multiple teams (OZ, Creit-Tech, etc.) to figure out release schedules and plans to handle each. |
Co-authored-by: Zach Fedor <zachfedor@gmail.com> Signed-off-by: Pamphile Roy <23188539+tupui@users.noreply.github.com>
for more information, see https://pre-commit.ci
4 participants
Scaffold Stellar
Go from idea to app faster with a custom, pluggable CLI; industry-redefining composability powered
by Stellar Registry; and a customizable, modern frontend.
Project Description
Scaffold Stellar is an open-source developer toolkit for building decentralized applications (dApps)
and smart contracts on the Stellar blockchain. It helps developers go from idea to working full-stack
dApp faster by providing CLI tools, reusable contract templates, integration with Stellar Registry,
and a modern customizable frontend.
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:
contract invokebehavior and associateddeveloper ergonomics that leapfrog, rather than ape, other blockchain ecosystems, simplifying
testing, deployment, and interaction.
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:
https://communityfund.stellar.org/project/smart-deploy-yoj
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
(and enjoyed) in the Mexico City hackathon in March. -Shipped Testnet Registry frontend (current
URL: https://testnet.rgstry.xyz/) and added relevant Testnet contracts & Wasms to it ahead of
Mexico City hackathon, as requested by SDF DevRel
the official SKILL.
Past Deliverables
Workstream 1 - Stellar Contract Registry: Launch + Trust + Reproducibility
D1. Registry UI (beta) shipped and publicly deployed
Testnet Registry frontend is live at https://testnet.rgstry.xyz/
D2. Namespaces + Security Council operationalization
Wasms and contracts can only be deployed to
unverifiednamespace by general users; findunverifiedWasms & contracts in the testnet registry with theunverified/channel prefix. Theseare tracked by a separate registry contract that is itself registered in the root/main registry with
the name
unverified(https://testnet.rgstry.xyz/contracts/unverified). This same sub-registryprefixing strategy will be used in mainnet (theahaco/scaffold-stellar#433)
to create dedicated sub-registries / prefixes for popular ecosystem projects & partners like
oz,blend, anddefindex. While the root / main registry contract is managed by the Registry SecurityCouncil multisig wallet, these other subregistries will be managed by each ecosystem's own wallet
(whether or not they use multisig is up to them).
D3. Registry documentation and publishing/consumption flows
Registry documentation exists at https://scaffoldstellar.org/docs/registry, which is also linked from
top navigation bar on https://testnet.rgstry.xyz/. Additionally, the Registry web app also shows how
to use registered contracts; see https://testnet.rgstry.xyz/contracts/unverified for an example.
D4. Supply-chain safety design implemented
"Flagging" behavior agreed upon by SDF project manager (Steph). "Registry as cross-contract proxy"
functionality implemented in theahaco/scaffold-stellar#461. Additional
functionality based on contract & wasm flagging to be implemented in Q2,
theahaco/scaffold-stellar#452, then communicated to ecosystem.
D5. Reset/reseed tooling for testnet & futurenet
Implemented in https://github.com/theahaco/registry-indexer/pull/3; to be tested during next Testnet
reset.
D6. Publish standard OpenZeppelin-based contracts into the registry
See
oz-prefixed Wasms here: https://testnet.rgstry.xyz/wasmsWorkstream 2 - Scaffold Stellar Extension/Plugin System + Integrations
D7. Extension/Plugin system shipped
Core extension system shipped in theahaco/scaffold-stellar#414; reporter
extension shipped in theahaco/scaffold-stellar#463.
D8. Wallet integration expansion via wallet kit
Support for all wallet modules shipped in
theahaco/scaffold-stellar-frontend#204.
D9. Indexing services and API integrations as extensions
Extensively researched and built with Goldsky to build Stellar Registry UI, and determined this
offering is both too immature to build as a Scaffold Stellar Extension for now, as well as being too
much of an edge case for how the extension system ended up working. We now have prior art to use to
implement a Goldsky extension later, which is being tracked in
theahaco/scaffold-stellar#164
Workstream 3 - Core DX Improvements
D10. New project page design update
Shipped in theahaco/scaffold-stellar-frontend#158
D11. Import existing Soroban contracts into Scaffold projects
Shipped in theahaco/scaffold-stellar#327
D12. stellar scaffold clean to improve iteration loops
The command was shipped here: theahaco/scaffold-stellar#352
Maintenance, Release Management, and Community Support
D13. Ongoing maintenance, releases, and field feedback loop
See all our releases with notes at https://github.com/theahaco/scaffold-stellar/releases
Proposed Impact
Scaffold Stellar has now launched Stellar Registry as a separate project, highlighting that this is
not merely a useful tool for learners and first-time Stellar builders. It's the foundation, the hub,
for much of the activity of the Stellar development community. With its recently-launched extension
system, Scaffold is poised to become the test ground, the proving site, for a diverse and composable
ecosystem of plugins, apps, and integrations.
This quarter we will continue to see Scaffold Stellar used as the entrypoint for the Stellar
ecosystem, both in documentation and at hackathons. The new extension system provides a focal point
for a themed hackathon of its own; we will advocate with DevRel to realize this. We will also reach
out to James Bachini to get Scaffold integrated directly into his web IDE, another project in this
Public Goods cohort.
Proposed Deliverables
D1: Support Stellar-Wallets-Kit v2
keep up to date with the latest standards in the ecosystem.
D2: Allow package manager of choice
their choosing (yarn, bun, deno, etc)
preference, but the JS ecosystem is fractured, with many people preferring more recent package
managers such as yarn, bun, and deno. Supporting these options within Scaffold prevents fracturing
the Stellar ecosystem, enabling people to use Scaffold while keeping their preferred JS tooling.
D3: BYOFrontend
create documentation for how community members can contribute their own frontend templates for use
with Scaffold Stellar.
default options of React and Vite, making the entire stack opinionated but also flexible.
D4: SKILL.md to help agentic workflows
workflows.
SKILL.mdto help agentic workflows theahaco/scaffold-stellar#394addition to, or rather than, coding by hand. This will make that experience more fool-proof and
powerful, preventing AIs from making silly mistakes.
D5: Improve Scaffold info on main Stellar docs
that have their own documentations sites, linking prominently to https://scaffoldstellar.org
stale information and highlight important resources, such as the Scaffold Showcase.
D6: Monitor releases of ecosystem projects
(perhaps in the form of GitHub issues or pull requests) when complex ecosystem dependencies, such
as Stellar-Wallets-Kit, are updated.
could cause Scaffold Stellar to not work at all, or to be out of date with the latest releases of
ecosystem projects. Updating the corresponding ecosystem project is not always as simple as
"increment version number" (although sometimes it is), since, in Stellar Wallets Kit's example, the
tool may be deeply integrated into Scaffold.
D7: Allow building for testnet when localnet unhealthy
when building for a testnet target. We will fix this.
easy-to-use, mature offering, enabling more confident building.
D8: Re-architect stellar scaffold build internals & update to latest best practices
made in stellar-scaffold-cli, the core of which is now nearly a year old. We will rework this core
logic to improve functionality, fix bugs, and adopt latest best practices. Some possible
improvements: optimize contracts if stellar-cli built with optimize feature; specify contract from
live network; rework entire environments.toml file name & structure.
Specify contract from live network theahaco/scaffold-stellar#346,
environments.tomlshould be...contract-clients.yml??? theahaco/scaffold-stellar#181enable us to continue to iterate on it quickly over the next year, providing the ecosystem with a
central tool that allows builders to quickly integrate various emerging solutions and best
practices.
Legal Acknowledgements