Skip to content

Q4 deliverables draft - #4

Closed
pselle wants to merge 39 commits into
proposals/stellar-registry-2026q4from
q4-deliverables
Closed

Q4 deliverables draft#4
pselle wants to merge 39 commits into
proposals/stellar-registry-2026q4from
q4-deliverables

Conversation

@pselle

@pselle pselle commented Sep 29, 2026 •
edited by github-actions Bot
Loading

Copy link
Copy Markdown

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/stellar-registry
First Released March 2026
Intake SCF-Public-Goods-Maintenance#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, a team of 13+
senior engineers deeply embedded in the Stellar ecosystem.

Copy/update rest of bio from Q3 proposal

Retroactive Impact

In Q3 2026...

Q3 Deliverables

✅ D1: Complete the Mainnet Launch (carried from Q2)

Description from last quarter:

With the registry contract live on mainnet, finish the public rollout: run the mainnet indexer
pipeline, point rgstry.xyz at the mainnet API and remove the "Coming Soon" banner, and land
secure-store/Ledger signing in the CLI (stellar-registry/cli#14) so admin operations never expose a
raw secret key.

Proof: mainnet data live and browsable at rgstry.xyz, the contract visible on Stellar Expert, and
named contracts resolvable via stellar registry CLI.

✅ Complete

⚠️ Pending

Q3 stretch goal (not hard-committed in Q3 deliverables; nice-to-have):

✅ D2: Release import_contract! (carried from Q2)

Description from last quarter:

Merge stellar-registry/cli#17 and publish the macro in released crates, documented with at least one working example and covered by integration tests.

Proof: a crates.io release containing import_contract!, linked docs and example, CI running the integration tests.

✅ Complete

The macro has landed! This was a hefty engineering task that entailed two large-scale re-architectures, code consolidation from other repositories (stellar-scaffold/cli repo is no longer the home of related macros import_contract_client! and import_asset!), and the creation of a new stellar-registry-name crate. With this release, we declared all Stellar Registry crates to have reached official beta, marking them all as version 0.1.0.

⚠️ Pending

Q3 stretch goal (not hard-committed in Q3 deliverables; nice-to-have):

Once this is done, people will have not just the documentation examples from crates.io and docs.rs, but a cookbook-style example using real working code.

✅ D3: Flagged Contract Enforcement at Build Time (carried from Q2)

Description from last quarter:

Extend import_contract! / import_contract_client! to fail compilation when the referenced Wasm or Contract is flagged in the Registry, building on the on-chain flagging that shipped in April.

Proof: a test demonstrating a flagged contract causes a build failure, and documented behavior.

✅ Complete

✅ D4: Finish Search, Pagination & Sorting on rgstry.xyz (carried from Q2)

Description from last quarter:

Extend server-side search to contracts (stellar-registry/indexer#24), fix search-result updating (stellar-registry/ui#22), and ship pagination and sorting so the explorer handles 1,000+ entries without degraded load time.

Proof: live on rgstry.xyz; search, pagination, and sorting demonstrated against a 1,000+ entry dataset.

✅ Complete

✅ D5: Contract Explorer, Deploy Button & Verified-Build Badges (carried from Q2)

Description from last quarter:

Ship the remaining explorer features: the embedded Contract Explorer on contract detail pages, a "deploy this Wasm" button, the remaining stellar contract info meta fields surfaced on detail pages, and verified-build status from Stellar Expert on contract detail pages.

Proof: all features live on production rgstry.xyz, manually verified against at least one mainnet contract.

✅ Complete

⚠️ D6: Governance Operations UI

Description from last quarter:

Ship the governance proposal forms (stellar-registry/ui#51): propose adding a Wasm or contract to the root registry, creating a subregistry, or changing owners — executed through the Tansu-DAO-gated registry manager contract that merged in Q2.

Proof: a governance proposal created from rgstry.xyz, voted on in Tansu, and executed on-chain via trigger, with the transaction linked.

✅ Complete

Tracking issue: stellar-registry/ui#51. A new Governance section on rgstry.xyz hosts one form per operation. On testnet, a form builds the on-chain outcome transaction, pins proposal.md to IPFS, and creates a Tansu proposal signed with the user's wallet. On mainnet, the form opens a prefilled issue in https://github.com/stellar-registry/gov.

⚠️ Pending

✅ D7: Registry Documentation & Education (carried from Q2)

Description from last quarter:

Publish the Registry docs site and video series covering publishing a Wasm, deploying named and unnamed contracts, using import_contract!, and publishing/releasing via the verified-build CI workflow.

Proof: documentation live on the Registry docs site and videos on The Aha Company's YouTube channel.

✅ Complete

⚠️ Pending

Q3 stretch goals:

✅ D8: Support named G-addresses

Description from last quarter:

Just as Registry today allows giving names to Wasms and Contracts, expand it to also allow giving names to G-addresses. These will be displayed in the rgstry.xyz UI, so that the "Deployer" and "Admin" fields become human-friendly names.

Value to ecosystem: a central, open, and collaborative system to add human-friendly names to G-addresses will allow other Stellar tools such as Stellar.Expert to also show friendly names, making the entire ecosystem more usable by existing participants and more welcoming to newcomers.

Proof: code shipped; address system available, documented, and advertised to the community; more than just Aha addresses added and available.

✅ Complete

Scope was narrowed during Q3 to foundational contract-level support; see tracking issue stellar-registry/cli#51.

Displaying names in the rgstry.xyz UI (e.g. "Deployer" and "Admin" fields), CLI support, documentation and community outreach, and onboarding non-Aha addresses will be proposed as Q4 work.

✅ D9: Surface emerging Source Verification information

Description from last quarter:

The Registry team submitted a proposal for the Source Verification system RFP. Whether or not our team is awarded this contract, Q3 will see the finalization of underlying SEP-58 and the launch of independent Source Verification services. Registry is a natural place to surface and organize this information and make it useful to the ecosystem.

Value to ecosystem: As the hub that makes Wasms on Stellar discoverable and reusable, Registry is a natural place to surface the Wasm metadata added by SEP-58. Registry is also not a source verification service, but a neutral third party that hosts the information provided by many source verification services. A lot of information is being added to the blockchain by this new standard, and Registry gives everyone a way to view and make sense of this information.

Proof: all SEP-58 fields viewable on rgstry.xyz; verification status of those fields by independent Source Verification services also shown in a way that exposes, rather than flattens, disagreement.

✅ Complete

⚠️ Pending

✅ D10: guide Tansu evolution to support Registry needs

Description from last quarter:

Harnessing Tansu for Registry's governance required significant effort and an unsatisfying technical workaround (see above discussion of Tansu-DAO-gated registry manager). We will collaborate with the Tansu team to guide Tansu's evolution, either obsolescing this workaround or sculpting it into a more general and generally-usable shape.

Value to ecosystem: whether for security guarantees as in the case of Registry, or just for open & participatory governance of open-source projects, on-chain governance provides a crucial role to any blockchain ecosystem. Registry's partnership with Tansu ensures the maturity of this solution for all community projects.

Proof: Registry Tansu Manager contract either migrates out of the stellar-registry repository to Tansu, becoming easier to use for all ecosystem projects, or becomes altogether unnecessary.

✅ Complete

⚠️ Pending

✅ D11: Registry GH Workflow to publish Wasms and upgrade contracts

Description from last quarter:

Wrap the stellar-expert/soroban-build-workflow and add Registry-specific things:

  • build with stellar scaffold build instead of stellar contract build to ensure inter-contract dependency build order correctness
  • when already-published Wasms are updated with new versions, publish these new versions to Registry

We are intentionally leaving contract upgrades as future work, as this gets into the thorny issue of migrations. It is best to leave contract upgrades as a manual task until tooling around migrations has matured.

This task requires research into how to securely provision keys which only have permission to invoke publish on the registry and can be stored in a GitHub workflow and which do not have risky privilege levels.

Proof: new repository available at, say, stellar-registry/gh-build-workflow. Documented and tested in production with the Registry wasm itself.

✅ Complete

⚠️ Pending

✅ D12: UI: Expose full contract version history

Description from last quarter:

The Registry API now exposes full version history, which notably extends into the full history of the blockchain, beyond the launch of the Registry contract itself. This information is not yet exposed in the rgstry.xyz UI. This deliverable addresses that mismatch.

Value to ecosystem: making contract upgrades easy to find and analyze aids in troubleshooting and full-blockchain comprehensibility.

Proof: Contract detail pages on rgstry.xyz/contracts display information about full contract history.

✅ Complete

⚠️ Pending

Stretch Goal: UI improvements to make "Versions" experience consistent across app: stellar-registry/ui#63

✅ D13: Documentation consolidation & redesign; potential migration of rgstry.xyz

Description from last quarter:

Implement new logo and design elements, secured in Q2, across rgstry.xyz site and other Registry properties such as GitHub. Organize videos created as part of D7 into landing page and other relevant locations throughout rgstry.xyz.

Discuss with ecosystem partners and SDF potential for a new domain for Registry: rgstry.xyz was never intended to be permanent. Registry could live under an SDF-owned domain, such as registry.stellar.org. This, in turn, may require frontend redesign, swapping current subdomain-based network specification (testnet.rgstry.xyz / stellar.rgstry.xyz) for URL-based specification. Depending on scope, the actual implementation of any such plan may be a Q4 concern.

Value to ecosystem: consolidates Registry documentation to a single, searchable place, making it simple to onboard and make the most of Registry.

Proof: redesigned site live, videos highlighted throughout, and question of domain's permanent home settled with decision documented and justified.

✅ Complete

⚠️ Pending

  • domain move discussion: no public link. History of discussion:

    • @chadoh raised the issue in a thread within SDF Slack; no one responded
    • @chadoh to raise again in Stellar Community Call when presenting Registry (see D7)

✅ D14: Extend import_contract! macro to support SAC and XLM

Description from last quarter:

Currently it is difficult to work with Stellar Asset Contracts, you need to know the asset encoding or provide the contract Id. Furthermore, writing unit tests which use SACs, particularly the native xlm asset, are difficult. We have previous work which helped this and is our guess the number contract. The other big improvement is for testing on a standalone network. Currently the xlm SAC isn't deployed by default on standalone quickstart image, this work would make this happen lazily on a contract's deployment.

Value to ecosystem: make it fun and easy for new developers to use and test SAC assets, especially the native.

Proof: published macro which can detect if a contract is a stellar asset contract and generate the required code to make using and testing the asset easy.

Note that import_asset! was already available and reasonable as an alternative at the end of Q2. The goal here is to ensure that import_contract!(xlm) and similar (such as import_contract!("circle/usdc")) work as-expected, so that users have a choice between import_asset! and import_contract!, where import_contract! alternative works for any SAC registered in stellar.rgstry.xyz.

✅ Complete

✅ D15: Verified Build Integration with Stellar Expert

This is copied from D6 in Q2, as outlined in the Q3 Proposal discussion. It was not hard-committed in the Tansu vote, but was soft-committed in the linked discussion.

Description from Q2:

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.

Extra details from Q3 Proposal discussion:

There was some real confusion amongst our team about the goal here. The initial Q2 D6 milestone was about helping our users implement the Verified Build workflow from Stellar Expert. In our write-up of what we did in the quarter, we instead referenced our own use of the Stellar Expert verified build workflow.

While this served as useful research for how to help our users, it did not satisfy the original task. D6 should have also been marked as a carry-over for Q3.

In addition, in our "completion notes" for D6, we stated that we were targeting contract pages, "since we established Stellar Expert has no Wasm-level pages." We've changed our thinking on this, as documented in a new issue, stellar-registry/ui#38. This is a sub-issue of our original tracking issue stellar-registry/cli#35, which we will continue to use as our tracking issue for Q3.

✅ Complete

Q3 Stretch Goals

Proposed Q4 Impact

Overarching Q4 story: Registry is ready, now drive adoption.

Q3 saw Registry become a sophisticated product offering huge productivity gains to any team that adopts it. And: the more everyone adopts it, the more everyone benefits. In Q4 we accelerate those gains.

We'll also ship the stuff early adopters have already asked for.

Proposed Q4 Deliverables

D1: Help Community Projects Use Registry Internally

Work intensively with at least two key partners to onboard their projects to Registry, specifically focusing on improvements to their toolchains and processes. This deliverable is about getting partners to use Registry in their own workflows. Along the way, we will discover Registry gotchas, improving the product to accelerate further rollout.

Possible partners & projects: XOXNO, Reflector (Orbitlens), Stellar Broker (Orbitlens), Crossmint (Overcat), Rozo (Shawn), LiFi, Soroswap (Palta Labs / Esteblock).

Value to ecosystem: more teams are saving time by using Registry and their contracts and Wasms are easier to find & use for the rest of the ecosystem.

Issue: stellar-registry/ui#102

Proof:

  • Merged PRs to integrate Registry into their codebases/workflows
  • Partner teams' contracts & Wasms exist on Registry and are owned by their teams' accounts

D2: Help Community Projects Show Registry Info

Starting with Stellar.Expert, we'll help community partners display Registry info, turning opaque hashes and IDs into human-friendly names.

Value to ecosystem: in the systems that people are already relying on, contracts and Wasms are identified by human-friendly names and versions, rather than opaque hashes and IDs.

Issues:

  • stellar-registry/indexer#TODO: Update Stellar.Expert to show Registry names/versions in place of Wasm hashes and contract IDs, when available

Proof:

  • Linked issue closed with implementing PR
  • Registry info displays on Stellar.Expert when available

D3: Developer outreach & education

We will continue to present and teach about Registry at Stellar community events and support other teams who do the same.

Value to ecosystem: help people learn about and onboard to Registry.

Issues:

Proof: links to recorded videos or event links

D4: Smart account support in the account namespace

The account namespace shipped in Q3 only accepts classic G-addresses: register_account rejects contract addresses with NotAccountAddress. Smart wallets such as Nido (passkey-based) are contract accounts (C-addresses), so their users can't get a name today.

Issues:

  • stellar-registry/contracts#TODO: Accept smart-account contract addresses in register_account and the account lifecycle functions, while keeping them distinct from entries in the contract namespace
  • nidohq/nido#TODO: Add wallet names to Stellar Registry

Value to ecosystem: one naming system for every kind of Stellar account, so passkey and other smart-wallet users get the same human-readable names as classic accounts.

Proof: registry contract released with smart-account support; at least one Nido wallet registered under a name and resolvable on rgstry.xyz and from the CLI.

D5: Named G-addresses, from contract to ecosystem (follow-on from Q3 D8)

Q3 shipped named G-address support in the registry contract (stellar-registry/contracts#37, stellar-registry/contracts#38). Make it usable and adopted.

This follows D4 intentionally: either style of named account (whether backed by a G-address or a smart account C-address) must be supported in all situations.

Issues:

  • stellar-registry/ui#TODO: Display account names anywhere accounts appear (e.g. "Deployer" and "Admin" fields)
  • stellar-registry/ui#TODO: Governance form to request named account in root Registry
  • stellar-registry/cli#TODO: register, resolve, and manage named (G- or C-) accounts
  • stellar-scaffold/cli#TODO: Document Registry's named (G- and C-) account support
  • stellar-registry/ui#TODO: Work with partner network to register names for the (G- and C-) accounts listed in their Wasms & contracts
  • stellar-registry/indexer#TODO: Show Registry's (G- & C-) account names in Stellar.Expert
  • stellar-registry/contracts#TODO: Create a SEP for resolving named G-addresses, so wallets and other tools can adopt the same names

Value to ecosystem: human-readable names for accounts, not only contracts & Wasms; reduce copy-paste mistakes and make on-chain activity legible.

Proof: names shown on rgstry.xyz and resolvable from the CLI; docs published and announced; named addresses registered by at least one team other than Aha; SEP draft or discussion linked.

D6: Simplify import_contract! testing

import_contract! works well on testnet and mainnet, but local development and unit tests need a registry with the depended-on contracts already registered, which each team has to set up themselves. Build the workaround from stellar-registry/cli#64 into the library

Issue: stellar-registry/cli#65

Value to ecosystem: teams adopting import_contract! get a working dev and test setup without retracing our steps.

Proof: linked issue address with a PR using a newly-cut release of stellar-registry crate

D7: Contract Details UI Revamp

The amount of information shown on Contract Details pages has grown, and it's starting to feel cluttered. Let's clean it up and prioritize what's important.

D8: Fix core deploy workflow when using Secure Store

When following security best practices, keeping secret keys and seed phrases off the file system and instead using macOS Secure Store or a hardware wallet like Ledger, the Registry CLI falls victim to an upstream Stellar CLI bug.

Issue: stellar-registry/cli#14

Value to ecosystem: No longer force users into clumsy and potentially insecure workarounds for core Registry CLI workflows.

Proof: Issues and PRs created in https://github.com/stellar/stellar-cli, and communications sent to Stellar CLI via our shared Slack channel to attempt to secure a review of these issues & PRs.

D9: stellar-registry/actions maturation & adoption

Q3's D11 saw us add automatic Wasm publishing to Registry via GitHub Workflow, added to Registry's own Wasm in stellar-registry/contracts#53. In Q4 we add contract upgrades to the core actions workflow, add more discerning Mainnet publish pathway, and adopt these workflows in all Aha-maintained projects. Along the way, we turn any rough edges or tooling/documentation gaps into new issues or PRs.

Issues:

  • stellar-registry/actions#TODO: add "Contract upgrade" workflow step
  • stellar-registry/actions#TODO: add human-initiated "Mainnet publish/deploy" workflow step
  • stellar-scaffold/ui#TODO: adopt stellar-registry/actions for Wasm publish & contract upgrade
  • stellar-registry/oz-combined-wasms#TODO: adopt stellar-registry/actions for Wasm publish & contract upgrade
  • Consulting-Manao/tansu#TODO: adopt stellar-registry/actions for Wasm publish & contract upgrade
  • nidohq/nido#TODO: adopt stellar-registry/actions for Wasm publish & contract upgrade
  • stellar-registry/perch#TODO: adopt stellar-registry/actions for Wasm publish & contract upgrade
  • Moonlight-Protocol/soroban-core#TODO: adopt stellar-registry/actions for Wasm publish & contract upgrade

Value to ecosystem: maturation of stellar-registry/actions ahead of Q1 rollout to partner teams and broader ecosystem; simplified & automatic best-practices publishing of Wasms with associated contract upgrades for all projects that adopt the workflow.

Proof:

  • Issues closed with implementing PRs
  • Successful workflow runs on linked Aha repos

Metrics loaded from PG Atlas

PG Atlas
90d Contributors
Pony Factor
Adoption

Legal Acknowledgements

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

@pselle pselle assigned pselle and unassigned pselle Sep 29, 2026
@pselle
pselle force-pushed the q4-deliverables branch 2 times, most recently from 4e3b974 to a96a30a Compare October 2, 2026 18:33
@pselle
pselle marked this pull request as ready for review October 2, 2026 18:33
chadoh
chadoh reviewed Oct 5, 2026
View reviewed changes

@chadoh chadoh left a comment •
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good stuff. I can add my ideas as separate deliverables tomorrow, but here were my rough notes before I looked at this; def some overlap:

# overarching story for Q4: Registry is ready, now drive adoption

Registry is now a sophisticated product that offers huge productivity gains across the Stellar ecosystem. Now we help people unlock those gains. And let's ship the stuff they already said they want, and that we know will help them do even more with Registry.

- Onboard N community partners (2 or 3?)
  - personalized intro session for their teams
  - send PRs to integrate Registry into their codebases/workflows
  - transfer authorship/admin rights on Registry Wasms/Contracts/Accounts to them
- Stellar.Expert to show Registry info
  - Any other "get them to use Registry" products/partners to target?
- All outstanding "stretch goals" from Q3 roadmap
  - including `import_contract!` macros; we need this early so Scaffold can consume it
- G-address maturation
  - support C-address accounts (smart accounts)
  - governance forms to request them
- `stellar-registry/actions` maturation and adoption throughout Aha-maintained contracts
  - also make actual create `upgrade` proposal on Tansu
- UI refresh
  - debugger for SACs
  - less space taken by metadata
  - page-per-function for debugger (show list of all functions in sidebar, like RAEN, with a separate URL for each)
  - URL-encode the filled values in the debugger
  - implement [Soroban Simulator](https://theahaco.github.io/soroban-sim/) to bypass `simulate` network call

Comment thread docs/projects/stellar-registry.md Resolved
Comment thread docs/projects/stellar-registry.md Resolved
@pselle

pselle commented Oct 6, 2026 •
edited
Loading

Copy link
Copy Markdown
Author

Go forth and push your commits!

For onboarding partners, my only hesitations there are to have a clear idea of the who, and that they're on board, before we put it in our concrete goals. For example, we manage OZ's published right now, right? Could we get them onboarded? Does XOXNO have any relevant contracts for us to work together on? that line of thinking.

@github-actions

github-actions Bot commented Oct 6, 2026

Copy link
Copy Markdown

🤖 Automated Housekeeping: I detected merge commits in this branch. To keep our history linear, I have automatically rebased your changes onto main.

⚠️ Note for CLI users: If you are working locally, please run git pull --rebase before your next push to sync your local history.

@pselle Claude

pselle commented Oct 6, 2026

Copy link
Copy Markdown
Author

The failing sync check (PG Award Proposal - Sync PR Body) isn't caused by this PR's changes. Its "Automatic Rebase and Linearize" step flags any merge commit between main and the head. The one it finds is d55b88d, the merge of #3, which is on our base branch proposals/stellar-registry-2026q4. The step then tries git rebase origin/main and fails. The branch was not rebased or changed, despite the bot's comment.

This workflow is inherited from the upstream SCF repo. It will fail the same way on every push to any PR targeting the proposals branch, so a re-run won't help. Its later step would also overwrite the PR body with the file contents. Fixing it means disabling or scoping this workflow in our fork, which is outside this PR.

Generated by Claude Code

@github-actions

github-actions Bot commented Oct 7, 2026

Copy link
Copy Markdown

🤖 Automated Housekeeping: I detected merge commits in this branch. To keep our history linear, I have automatically rebased your changes onto main.

⚠️ Note for CLI users: If you are working locally, please run git pull --rebase before your next push to sync your local history.

chadoh and others added 20 commits October 7, 2026 17:41
@chadoh @github-actions
d5 complete
9571e9e
@chadoh @github-actions
d6 updates
1daee41
@chadoh @github-actions
d8 details
6d9c787
@chadoh @github-actions
d9 notes
6ee4334
@chadoh @github-actions
d10 notes
33ad0ce
@chadoh @github-actions
logo and icons complete
60662fc
@chadoh @github-actions
d5 pending verified build badges
6f57a8b
@chadoh @github-actions
d5 done; d15 close; d7 half; d12 has notes
5f745fa
@chadoh @github-actions
d7 formatting
21dec7e
@chadoh @github-actions
d14 complete
9759b24
@chadoh @github-actions
d15 complete
e7f8b1d
@chadoh @github-actions
docs stuff mostly done; perch was created
fc10f71
@chadoh @github-actions
mark complete/pending status in title line
2a39acc
@pselle @claude @github-actions
Q3 progress: D6 governance forms, D8 named G-addresses, D9 source ver…
27197e6 
…ification

- D6: list merged governance form PRs; subregistry form and live
  end-to-end proposal remain pending
- D8: mark complete as scoped down to contract support
  (contracts#37, SCF-Public-Goods-Maintenance#38); UI/CLI/docs/adoption proposed for Q4
- D9: list SEP-58 indexer + Wasm page work; contract page and
  independent verifier status remain pending

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@pselle @claude @github-actions
D9: drop note about independent verifier status
b6c2a49 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@claude @github-actions
D10: mark complete, link Tansu merge of registry manager
d2b7a23 
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RBsh3GR3B9UhLBNTv8eqPJ
@claude @github-actions
D9: ui#83 merged, move to complete
944ebd4 
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RBsh3GR3B9UhLBNTv8eqPJ
@claude @github-actions
D9: mark complete; remaining RFP items are outside our control
b15cae3 
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RBsh3GR3B9UhLBNTv8eqPJ
@claude @chadoh @github-actions
Apply review suggestions on D6 and D8 wording
b72a338 
Co-authored-by: Chad Ostrowski <221614+chadoh@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RBsh3GR3B9UhLBNTv8eqPJ
@claude @github-actions
D6: ui#81 and gov#3 merged, move subregistry form to complete
01bfe35 
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RBsh3GR3B9UhLBNTv8eqPJ
@pselle Claude

pselle commented Oct 7, 2026

Copy link
Copy Markdown
Author

The sync workflow has now succeeded on a later push, and it did what this comment warned about. It rebased the branch onto main, so every commit now has a new SHA and github-actions[bot] as committer. It also replaced the PR description with the file contents; the description has since been restored. The file contents are unchanged, and the PR still merges cleanly into proposals/stellar-registry-2026q4.

Generated by Claude Code

@chadoh
chadoh deleted the branch proposals/stellar-registry-2026q4 October 8, 2026 19:22
@chadoh chadoh closed this Oct 8, 2026
@chadoh

chadoh commented Oct 8, 2026

Copy link
Copy Markdown
Member

Thanks @pselle; this PR got all fucked up because the target branch had the name that the upstream repo keys on. I'm going to move this all to a newly-created proposals/stellar-registry-2026q4 branch. I'll list you as co-author so you get your GitHub stats.

@chadoh
chadoh deleted the q4-deliverables branch October 8, 2026 19:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@chadoh chadoh chadoh left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@pselle @chadoh @claude