PG Award Proposal: Stellar Scaffold

[chadoh]

Stellar Scaffold

Go from idea to app faster with a custom, pluggable CLI; a multi-framework template system; and a
customizable, modern frontend.

Category	Developer Experience
Website	https://scaffoldstellar.org/
Repository	https://github.com/stellar-scaffold/cli/
First Released	May 2025
Intake	soft-launch
Budget Requested	50000

Project Description

Stellar Scaffold 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, first-class integration with Stellar
Registry (now incubated out into its own project), and modern, customizable frontend templates for
multiple JS frameworks.

Team & Experience

Stellar Scaffold 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 Stellar Scaffold 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

Stellar Scaffold 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 Stellar Scaffold aligned with
what developers expect from modern, full-stack tooling.

Retroactive Impact

• Stellar Registry graduated into its own project. What began as a Stellar Scaffold workstream
  matured enough over the last two quarters to be spun out as an independent public good with its own
  team, repos, and roadmap. The extraction of the Scaffold CLI into its own focused repository was
  completed this quarter (split: extract scaffold-cli from monorepo stellar-scaffold/cli#535), and Scaffold remains the
  primary integration surface for publishing and consuming Registry contracts. This is the incubation
  model working as intended.
• Same-cycle Stellar Protocol 27 support. The CLI, contract templates, and generated projects
  were upgraded to Protocol 27 (feat: upgrade to stellar protocol 27 stellar-scaffold/cli#549) and released
  immediately (2026-06-30), so builders scaffolding new projects were never stuck on an old protocol.
• Continuous releases. Three stellar-scaffold-cli releases shipped this quarter (v0.0.22,
  v0.0.23, v0.0.24) plus supporting crates, with notes:
  https://github.com/stellar-scaffold/cli/releases
• Upstream documentation contributions, e.g. improving prerequisites on the official Stellar docs
  (docs: Add Docker to Scaffold Stellar prerequisites stellar/stellar-docs#2267).
• Stellar Scaffold remains in the "recommended resources" for Stellar hackathons and is recommended
  in the official SKILL.

Past Deliverables

Q2 in summary. We made Q2 a deliberate re-architecture quarter. Three structural efforts — the
Registry split, the multi-framework Template Monorepo, and the Protocol 27 upgrade — consumed most of
the quarter and touched nearly every deliverable below. That investment is what makes the Q3 list
finishable: wallet integration now lands once in a shared package instead of per-template, community
templates have a real extension point, and the config-file migration has its first slice shipped. Of
the eight committed deliverables, one shipped fully, two shipped substantially, and the remainder
have completed discovery/design with implementation carried into Q3 — several with open PRs already.

D1: Support Stellar-Wallets-Kit v2

• Update to Stellar-Wallets-Kit v2, released v2 in Feb 2025, to streamline Developers' experience
  and keep up to date with the latest standards in the ecosystem.
• Measure: update shipped in frontend
• Issue: stellar-wallets-kit v2 stellar-scaffold/cli#441

Shipped. Upgraded integration, improved UX, and network polling workaround merged in
stellar-scaffold/ui#241. The Template Monorepo restructure (see D3, D8) moved
wallet integration into the shared @stellar-scaffold/app-lib package, so the v2 upgrade now lands
once for every framework template instead of once per template. Finishing this is committed in Q3
(see Proposed D3).

D2: Allow package manager of choice

• Rather than forcing people to use NPM with Scaffold, allow them to pick the JS package manager of
  their choosing (yarn, bun, deno, etc)
• Measure: feature shipped, tested, & documented
• Issue: Allow users to use pnpm/package manager of choice stellar-scaffold/cli#162

Shipped. Core package-manager-agnostic behavior merged in
stellar-scaffold/cli#345, with follow-up improvements in
stellar-scaffold/cli#491, released in stellar-scaffold-cli v0.0.24. The
tracking issue is closed.

D3: BYOFrontend

• Create two new Aha-maintained Scaffold frontend plugins: 1. no frontend, 2. Svelte. In addition,
  create documentation for how community members can contribute their own frontend templates for
  use with Stellar Scaffold.
• Measure: feature shipped, tested, documented.
• Issue: BYOFrontend stellar-scaffold/cli#161

Substantially shipped via the Template Monorepo effort
(stellar-scaffold/cli#543, stellar-scaffold/ui#234,
and stellar-scaffold/cli#564):

• The single React frontend repo became a multi-framework template monorepo (templates/react,
  templates/svelte, plus a shared app-lib package for wallet, storage, and formatting logic),
  delivering the official Svelte template.
• stellar scaffold init --template accepts either an official framework name (e.g. svelte) or an
  org/repo community template, establishing the "bring your own frontend" path.
• A new scaffold.yml config: section lets any template declare where its contracts, TypeScript
  bindings, and contract clients live, so community templates can follow their own framework
  conventions.
• --no-template or --template none allows a contract-only workflow without any frontend

A community-template contribution guide — was not delivered in Q2 and is explicitly committed in Q3
(Proposed D5).

D4: SKILL.md to help agentic workflows

• Add SKILL.md to Stellar Scaffold repository to facilitate more powerful and accurate AI & agentic
  workflows.
• Measure: feature shipped, tested, and documented.
• Issue: SKILL.md to help agentic workflows stellar-scaffold/cli#394

Not shipped in Q2; design work completed. The Registry split re-scoped this deliverable: each product
now needs its own agent-facing doc (Scaffold's SKILL.md hosted at scaffoldstellar.org, Registry's
own alongside its site), and the template monorepo introduced a second need — in-project agent docs
that init carries into generated end-user projects. The re-scoped design is committed in Q3 (see
Proposed D4).

D5: Improve Scaffold info on main Stellar docs

• Minimize the info on the Stellar Scaffold page on the main Stellar docs in line with other tools
  that have their own documentations sites, linking prominently to https://scaffoldstellar.org
• Measure: new documentation page shipped to main Stellar docs
• Issue: Improve Scaffold info on main Stellar docs stellar-scaffold/cli#361

Shipped. Scope was agreed in the issue discussion (minimize the page, link prominently to the
dedicated docs site), and smaller upstream improvements shipped in the meantime
(stellar/stellar-docs#2267). Multiple pages reworked on Stellar docs
(stellar/stellar-docs#2708) and contain pointers to updated documentation on
new, redesigned Scaffold docs site (stellar-scaffold/cli#577).

D6: Monitor releases of ecosystem projects

• For Scaffold itself and all projects that are built with it, provide automatic notifications
  (perhaps in the form of GitHub issues or pull requests) when complex ecosystem dependencies, such
  as Stellar-Wallets-Kit, are updated.
• Measure: system in place for notifying Scaffold team of ecosystem project updates
• Issue: Monitor releases of ecosystem projects stellar-scaffold/cli#301

Not shipped; design discussion in the issue converged on an approach: scheduled CI (cron) jobs that
test against dependency releases (or HEAD/nightly builds for early warning), structured so that
projects built with Scaffold can inherit the same alerts. Our existing scheduled-update flow for
the OpenZeppelin example contracts serves as the prototype. Carried into Q3 as a stretch goal
(Proposed D9) behind the committed re-architecture work.

D7: Allow building for testnet when localnet unhealthy

• Scaffold currently requires running a local Stellar network, which it can do automatically, even
  when building for a testnet target. We will fix this.
• Measure: bug fix shipped
• Issue: Bug: Cannot build project for testnet if local network is unhealthy stellar-scaffold/cli#267

Not shipped as a point fix — investigation showed the network-health check is baked into the build
internals being reworked under D8, and that a point fix would fight the old config model. The durable
fix lands with the Q3 scaffold.yml networks rework (Proposed D2), which decouples target-network
builds from localnet state; the new scaffold doctor command (Proposed D1) then gives users
self-serve diagnosis of unhealthy localnets instead of a confusing failure.

D8: Re-architect stellar scaffold build internals & update to latest best practices

• Various bugs and sub-optimal behavior can be pinned on some early, messy architectural decisions
  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.
• Measure: features shipped, tested, and documented.
• Issues: Include optimize option in stellar scaffold build stellar-scaffold/cli#329,
  Specify contract from live network stellar-scaffold/cli#346,
  environments.toml should be... contract-clients.yml??? stellar-scaffold/cli#181

Major structural work shipped:

• Extracted the Scaffold CLI into its own focused repository as part of the Registry split
  (split: extract scaffold-cli from monorepo stellar-scaffold/cli#535).
• Rebuilt init, upgrade, and clean around the new template monorepo, factoring init into
  three clean steps — acquire, instantiate, prepare — replacing the original single-repo degit logic
  (Template Monorepo stellar-scaffold/cli#543).
• Shipped the first slice of the new scaffold.yml configuration file (the per-template config:
  section), the replacement for environments.toml proposed in issue 181.
• Upgraded the toolchain to Stellar Protocol 27 (feat: upgrade to stellar protocol 27 stellar-scaffold/cli#549).

The discovery work here defined the remaining schema migration (networks and contract-client config)
and the --optimize passthrough, both committed in Q3 (Proposed D2).

Ongoing maintenance, releases, and field feedback loop

Regular tagged releases with notes continued throughout the quarter
(https://github.com/stellar-scaffold/cli/releases), including three stellar-scaffold-cli releases,
OpenZeppelin example-contract updates, and the Protocol 27 upgrade.

Proposed Impact

With Stellar Registry incubated out as its own public good, Stellar Scaffold enters Q3 with a sharper
scope: the front door of the Stellar ecosystem. The template monorepo shipped in Q2 turns "the
official React starter" into a multi-framework template system — Svelte is live, and the org/repo
template flag opens the door to community-maintained frontends, letting the ecosystem grow templates
without growing our payroll. Agent-facing documentation will make Scaffold the most reliable way for
AI-assisted builders (the majority at recent hackathons) to produce working Stellar dApps. And
scaffold doctor cuts the support burden that environment problems create at every hackathon.

We are deliberately committing to a shorter list this quarter than last: the Q2 re-architecture is
done, and Q3 is about finishing what it unblocked. Every committed deliverable below either has an
open PR, a shipped first slice, or a completed design from Q2 discovery.

A note on budget

The Registry split moves that workstream to its own proposal, but it does not shrink this one
proportionally: the template surface we maintain grew from one framework to a monorepo of shared
core + multiple templates (each needing e2e coverage, releases, and protocol upgrades), and Scaffold
remains the integration surface for Registry, wallets, and other ecosystem dependencies. The budget
now buys depth and reliability on that wider surface rather than breadth of new workstreams.

Proposed Deliverables

D1: Create scaffold doctor command

• A new command that examines and diagnoses environment problems in the user's project: wrong Rust
  toolchain, missing dependencies (e.g. Docker), an unhealthy localnet, incorrect scaffold.yml
  values.
• Measure: command shipped, tested, and documented.
• Issues: Create scaffold doctor command stellar-scaffold/cli#557 (and resolves the failure mode reported
  in Bug: Cannot build project for testnet if local network is unhealthy stellar-scaffold/cli#267)
• Ecosystem value: Q2 bug investigation showed that a large share of Scaffold support requests are
  environment problems, not Scaffold bugs. Self-serve diagnosis shortens time-to-first-success for
  new builders — especially at hackathons — and reduces maintainer support load across the ecosystem.
  It also provides value to projects bootstrapped by other means (not Scaffold) that end up with
  environment and version problems.

D2: Complete the scaffold.yml configuration migration

• Finish the CLI configuration rework begun in Q2: fold network and contract-client configuration
  into scaffold.yml (whose config: section shipped with the template monorepo), retire
  environments.toml, and pass through the --optimize flag to stellar contract build.
• Measure: new schema shipped, tested, and documented; environments.toml deprecated with a
  migration path; optimize passthrough shipped.
• Issues: environments.toml should be... contract-clients.yml??? stellar-scaffold/cli#181,
  Include optimize option in stellar scaffold build stellar-scaffold/cli#329
• Stretch: specify a contract from a live network as a project dependency
  (Specify contract from live network stellar-scaffold/cli#346)
• Ecosystem value: one obvious, well-named config file instead of a misleadingly-named split; this
  rework also decouples target-network builds from localnet state (the root cause behind issue 267)
  and enables per-framework directory conventions for community templates.

D3: Ship Stellar-Wallets-Kit v2 through the shared wallet module

• Land the in-review Wallets-Kit v2 upgrade in the shared @stellar-scaffold/app-lib package so all
  framework templates (React, Svelte, and future Vue) get the upgrade from a single integration
  point.
• Measure: upgrade merged and released across all official templates.
• Issue: stellar-wallets-kit v2 stellar-scaffold/cli#441 (implementation:
  feat: upgrade Stellar-Wallets-Kit to v2 stellar-scaffold/ui#241)
• Ecosystem value: keeps scaffolded apps current with the latest wallet standards, and validates the
  shared-app-lib architecture: one wallet integration maintained once, consumed by every template.

D4: Agent-facing docs: hosted SKILL.md + in-project AGENTS.md

• Publish a self-contained SKILL.md at scaffoldstellar.org teaching AI agents Scaffold as a system,
  and ship AGENTS.md files in generated projects (with init stripping contributor-only content so
  end users get docs scoped to their app).
• Measure: SKILL.md live and fetchable by URL; generated projects include a correct AGENTS.md;
  both documented.
• Issue: SKILL.md to help agentic workflows stellar-scaffold/cli#394
• Ecosystem value: many hackathon participants and serious builders prefer to use AI tools in
  addition to, or rather than, coding by hand. Accurate agent-facing docs make that experience
  fool-proof, preventing AIs from making silly mistakes both when scaffolding a project and when
  working inside one.

D5: Complete BYOFrontend: "no frontend" option + community-template guide

• Finish the remaining scope from Q2's BYOFrontend deliverable: a "no frontend" init option
  (contracts and clients without a UI layer) and a contribution guide documenting how community
  members build and publish their own framework templates for
  stellar scaffold init --template org/repo.
• Measure: no-frontend option shipped and tested; contribution guide published on the docs site; at
  least the existing official templates documented as reference implementations.
• Issue: BYOFrontend stellar-scaffold/cli#161
• Ecosystem value: closes out a Q2 commitment, and shifts template growth to the community — the
  ecosystem gets more framework options (Vue, Solid, etc.) without every template landing on one
  team's maintenance budget.

D6: Documentation consolidation & redesign

• Redesign the Scaffold docs website (taking inspiration from the new Registry site), update the
  tutorial to cover the latest Registry publish/deploy integration, complete the domain migration,
  and minimize the Scaffold page on the main Stellar docs to link prominently to the dedicated site.
• Measure: redesigned docs site live; tutorial updated; upstream Stellar docs page PR merged.
• Issues: Redesign docs website to match Registry stellar-scaffold/cli#556,
  update scaffold tutorial with latest Registry stellar-scaffold/cli#437,
  Improve Scaffold info on main Stellar docs stellar-scaffold/cli#361,
  Update domain to stellarscaffold.org stellar-scaffold/cli#550
• Ecosystem value: consolidates Scaffold documentation to a single, current place, minimizing stale
  information across the ecosystem and keeping the Registry integration path — now a cross-project
  concern — accurately documented.

D7: Ongoing maintenance & releases

• Regular tagged releases with changelogs, protocol upgrades, OpenZeppelin example-contract updates,
  issue/PR triage, and CI reliability work as the template matrix grows.
• Measure: regular tagged releases + changelogs + documented learnings from events.
• Ecosystem value: a "front door" tool must always work with the current protocol and ecosystem
  libraries; reliability is the feature.

D8 (Stretch): At least one ecosystem-contributed UI template

• Work with a specific community partner or host a hackathon to solicit at least one new UI template.
  This could be a new JS view engine such as Vue, or an existing view engine (React, Svelte)
  configured differently (such as React with NextJS and different styling opinions). This will be
  selectable via stellar scaffold init.
• Measure: template shipped with e2e coverage, selectable in init, documented.
• Issue: Create additional UI template stellar-scaffold/cli#558
• Ecosystem value: exercises the multi-template architecture with a third framework and serves as a
  worked example for the community-template guide (D5). Stretch rather than committed: we'd rather
  demand for Vue prove itself via the community path than pre-commit maintenance of a third official
  template.

D9 (Stretch): Monitor releases of ecosystem projects

• Implement the scheduled-CI monitoring approach designed in Q2: automatic notifications (issues or
  PRs) when complex ecosystem dependencies such as Stellar-Wallets-Kit publish updates, structured so
  projects built with Scaffold can adopt the same alerts.
• Measure: system in place for notifying the Scaffold team of ecosystem project updates.
• Issue: Monitor releases of ecosystem projects stellar-scaffold/cli#301
• Ecosystem value: ecosystem dependencies ship breaking changes; catching them early keeps Scaffold —
  and every project scaffolded from it — working and current.

D10 (Stretch): Anonymous usage telemetry

• Add basic, anonymous usage telemetry to the CLI (e.g. scaffold init counts, deploys per network)
  so the team can measure real adoption instead of relying on anecdote. Do this in conjunction with
  indexing already-available on-chain data, and prefer on-chain data as the source when possible.
• Measure: telemetry system shipped with clear disclosure; adoption metrics available to the team.
• Issues: https://github.com/stellar-scaffold/cli/issues/448,
  index all on-chain contracts to measure growth of those scaffold-built stellar-scaffold/cli#479
• Ecosystem value: lets us (and SCF) evaluate Scaffold's actual ecosystem impact quantitatively and
  prioritize future work by evidence.

D11 (Stretch): Interactive OpenZeppelin contract wizard

• An interactive CLI mirroring wizard.openzeppelin.com for adding OZ-based contracts to a Scaffold
  project (building on the draft in Add OZ wizard in scaffold cli stellar-scaffold/cli#391).
• Measure: feature shipped, tested, and documented.
• Issue: Interactive CLI to add OZ-wizard contracts stellar-scaffold/cli#156
• Ecosystem value: safe, audited building blocks become the path of least resistance for new
  contracts.

D12 (Stretch): Update starter app's Debug page

• Improve the generated app's contract Debug page: clearer results display, additional transaction
  details, and a persistent block-explorer link.
• Measure: updated Debug page shipped in templates.
• Issue: Update starter app's Debug page stellar-scaffold/cli#248
• Ecosystem value: the Debug page is many builders' first contract interaction; better feedback loops
  mean faster learning.

Metrics loaded from PG Atlas

Legal Acknowledgements

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

[ankeliu]

@chadoh Thanks for the submission, and for being upfront about what shipped versus what didn't. Per-deliverable, against the Q2 scope:

• D1. Stellar-Wallets-Kit v2: Well-engineered and substantial -- not a simple dependency upgrade. Review is in progress with some finishing touches, no major concerns. Effectively done; should not consume Q3 budget.
• D2. Package manager of choice: Fully shipped.
• D3. BYOFrontend (no-frontend + Svelte + community guide): Over 50% done by effort, not complete.
• D4. SKILL.md, D5. Stellar docs page, D6. dependency monitoring, D7. testnet build fix: Not shipped -- design work only, carried into Q3.
• D8. Re-architect build internals: Most of the Q2 effort went here. A substantial, real investment in future maintainability, and it explains the slippage on the rest.

On the budget. This was a $50K quarter scoped as D1 through D8. D2 and D8 landed, D1 is done pending merge, D3 is past halfway -- but D4, D5, D6, and D7 did not ship. That's a real gap between what was funded and what was delivered.
We're not looking to penalize the re-architecture call -- prioritizing D8 was the right long-term decision. But the Pilots approved $50K against all eight deliverables, and several of them didn't happen. So before the Q2 remainder is paid, we need you to break the $50K down across the eight deliverables and tell us the amount attributable to the work that wasn't completed. We'll deduct that from the outstanding Q2 payment.

This also keeps Q3 clean. Whatever you carry over is then funded fresh in the Q3 ask, rather than being paid once in the Q2 remainder and again in Q3. Send the per-deliverable breakdown when you can, and mark which carried items you intend to finish in Q3.

[zachfedor]

Hey @ankeliu, thanks for the feedback! We definitely understand the sentiment. The framing is fair and we agree with the principle: carried over work shouldn't be paid twice. We tried to scope things in a way this quarter that weren't simply pushing work from the previous quarter, but instead focused on new aspects of work that were revealed while investigating or implementing things. There was also a fair amount of work done last quarter on unexpected fixes and features, and we didn't know the best way to handle that or express it given the current workflow. Maybe that's something we could discuss? For example, lots of effort went into trying to juggle dependency issues stemming from the Protocol 26 release, which wasn't planned or listed as a Q2 deliverable but was still necessary. And in fact, we ended up having to do it all over again because some of our dependencies jumped straight to P27. How should we account for things like this in the future?

Before I do the effort breakdown, there are some corrections to the status you reviewed against. This is our fault, not yours. Migrating the repo into the new stellar-scaffold org left some issue/PR links broken, so the Q2 milestone under-reported what had landed. And worse, cross-repo closing keywords don't fire. So ui PRs that fix cli issues (e.g. fixes stellar-scaffold/cli#441) didn't auto-close the issue and several stayed open after their work merged. And lastly, sub-issues lost their milestone in the transfer. Four completed issues (i.e. #363, #366, #367, #368) sat outside the Q2 milestone entirely. The milestone showed 3 closed / 13 open; the accurate count is 9 closed. We've tried to clean those links up now and I've updated the deliverables above.

Finally here is our best judgement of the effort breakdown across those deliverables. You can see we tried to focus our work on the largest and most important tasks first.

┌──────────────────────┬──────────────────────────────────────────┬─────────┬──────────┐
│     Deliverable      │                Issues/PRs                │ Rough % │ $ of 50K │
├──────────────────────┼──────────────────────────────────────────┼─────────┼──────────┤
│ D1 Wallets-Kit v2    │ ui#241, 31d review cycle                 │ 13%     │ $6,500   │
├──────────────────────┼──────────────────────────────────────────┼─────────┼──────────┤
│ D2 package manager   │ #345 (partly Q1) + #491                  │ 7%      │ $3,500   │
├──────────────────────┼──────────────────────────────────────────┼─────────┼──────────┤
│ D3 BYOFrontend       │ ui#234 (bulk) + #543 share + #564 + #367 │ 24%     │ $12,000  │
├──────────────────────┼──────────────────────────────────────────┼─────────┼──────────┤
│ D4 SKILL.md          │ 19 words on #394                         │ 2%      │ $1,000   │
├──────────────────────┼──────────────────────────────────────────┼─────────┼──────────┤
│ D8 re-architect      │ #535 + #549 + share of #543/#234 + #363  │ 30%     │ $15,000  │
├──────────────────────┼──────────────────────────────────────────┼─────────┼──────────┤
│ D5 docs page         │ #2267 + #2708 (open)                     │ 4%      │ $2,000   │
├──────────────────────┼──────────────────────────────────────────┼─────────┼──────────┤
│ D6 dep monitoring    │ #301, partly subsumed by ui#234          │ 6%      │ $3,000   │
├──────────────────────┼──────────────────────────────────────────┼─────────┼──────────┤
│ D7 testnet fix       │ subsumed; #181 design                    │ 2%      │ $1,000   │
├──────────────────────┼──────────────────────────────────────────┼─────────┼──────────┤
│ Maintenance/releases │ 3 Q2 releases, CI, dependabot            │ 12%     │ $6,000   │
└──────────────────────┴──────────────────────────────────────────┴─────────┴──────────┘

These percentages can be roughly verified by comparing lines changed, number of commits, review volume within closed PRs, and length of calendar time during review discussions. I know these aren't the best proxies for real effort, and they certainly understate the amount of planning and side discussions happening for big design decisions. But at least it gives you something concrete to compare against and I think it does roughly correlate to our actual level of effort.

I hope that helps. Please let me know if there's any other info we can provide!

[zachfedor]

@aolieman, thanks for the metric badges. To make sure they're accurate, how can I associate the rest of the repos for the project? This project encapsulates https://github.com/stellar-scaffold/ui too. I looked at #117 as a reference, is it as simple as using the GH org as the value for Repository in the front matter table?

[aolieman]

how can I associate the rest of the repos for the project?

Anke sent some instructions a while back. It's possible you didn't receive them.

I can add the repo url to the table at the top of your proposal, if that's really what you want. My advice would be to only link your UI repo if it has significantly more tracked package downloads than the CLI. Otherwise it's going to lower the project's adoption score.

To get a preview of the UI repo metrics, you can enroll it by putting the SBOM Action in a GitHub workflow. Stats should be visible in PG Atlas an hour after uploading it's first SBOM.

More interesting for me is: do you have a way of tracking which projects are using Scaffold? Which adoption data does your team look at? I don't know if you git init a scaffolded project, but you could add the SBOM Action in the project dir to track those that get pushed to GitHub through PG Atlas.

[ankeliu]

@zachfedor Thanks for this, and for the correction on the milestone under-reporting: the broken cross-repo links and the four issues that fell out of the milestone in the org migration explain the gap between what the milestone showed and what actually landed. Good to have the accurate 9-closed picture.

On the P26/P27 dependency work you raised: that's a fair question and it's one we're settling as a general rule going forward. The principle we're landing on is that legit, necessary work done in place of a listed deliverable -- like the Protocol 26/27 dependency juggling -- shouldn't be treated as if nothing happened. We haven't enforced that consistently before, so we're applying it with some flexibility in this round.

Taking your effort breakdown together with that, we're setting the Q2 deduction at $3,000 -- covering the genuinely unshipped items (D4, D6, D7, and the docs page still open), not the re-architecture call or the dependency work. D1, D2, D3, and D8 are treated as delivered. The carried items get funded fresh in Q3, so nothing is paid twice.

If that works, we'll email you with next steps on payment for Q2 deliverables.

[ankeliu]

Summary

Ready for Q2 payment with a $3,000 deduction. Uneven delivery, honestly reported and resolved; Q3 slate needs trimming.

Q2 completion
Issues, resolved cooperatively. D1 (Wallets-Kit v2), D2, D3, and D8 landed; D4–D7 did not ship, as the D8 re-architecture consumed the quarter. A repo migration under-reported the milestone (showed 3 closed when 9 were); zachfedor corrected it and posted a full effort breakdown of the $50K. Deduction set at $3,000 for the unshipped items, with carried work funded fresh in Q3. Team also raised how to credit unplanned P26/P27 dependency work.

Q3 deliverables — discussion
Main concern is over-scoping. convergence asked Scaffold and Registry to mark some Q3 deliverables as nice-to-have so review isn't against an oversized list. tupui framed the miss as a project-management issue and cautioned against penalizing proposal/PM writing skill. Latest activity is an aolieman exchange on correctly associating CLI vs UI repos for PG Atlas metrics.

User Signal
No standalone user testimonials on the PR to date; engagement is from the reviewers (aolieman, tupui) rather than external users.

[github-actions]

Proposal Successfully Submitted to Tansu 🚀

The proposal has been uploaded to IPFS and submitted on-chain.

Tansu Link	View on Tansu
PR	#115
Proposal File	docs/projects/scaffold-stellar.md
Proposal ID	16
Proposal Title	Stellar Scaffold
Proposal CID	QmYg2M5noPCUJRAgBGqtudUNqhZxvdBqtLS7s3TJrA5W2y
Voting Ends At	1786475326
Network	testnet
Contract	CBXKUSLQPVF35FYURR5C42BPYA5UOVDXX2ELKIM2CAJMCI6HXG2BHGZA
Project Key	cd1a6cec242a72156c3a3b23b15146688ca76a52065f9b6f157a9e2711fbaabb

[zachfedor]

Thanks @ankeliu! We appreciate the response. As for Q3 deliverables, we recognized the scope problem while writing the proposal and we think we corrected for it before any review input. So we don't think it's necessary to reduce the scope again after the fact. And now that we have the repo migration and issue tracking wired up correctly, we can better stay on top of our velocity this quarter and deliver on time. Hope that helps!

[ankeliu]

Thank you for the reply @zachfedor, I will reach out by email for next steps regarding the Q2 payment!