Loading...
Supporting developers, startups, and full-fledged companies building on Stellar and Soroban
© 2025 Stellar Development Foundation
Subscribe to the Newsletter
By PG Atlas
Realizing the new Public Goods Award structure requires updates to one existing product and the development of one new system.
Tansu is an existing decentralized governance and versioning platform built on Soroban, already deployed on Stellar mainnet. It provides on-chain project registration, DAO-based proposals and voting (public and anonymous), badge-based membership, and IPFS content storage. The full documentation is on tansu.dev.
For the first enhanced decentralization Public Goods Award round (in Q2), Tansu needs targeted additions to support the PG Award voting workflow:
SCF Governance Space: Configure and deploy a dedicated SCF Governance organization on Tansu, including proposal templates and operational documentation.
NQG Score Integration: Bridge Tansu’s voting weight system with SCF’s dynamic NQG scores, enabling weighted voting based on governance reputation.
NQG Soulbound NFT (SEP-50): Implement dynamic, soulbound NFTs to represent NQG scores on-chain, with Freighter wallet compatibility and governance reputation visualization.
PG Atlas is a new system that provides the objective, transparent metrics backbone for funding decisions. It does not exist yet. The full technical architecture is documented in the working group repo.
The v0 goal is to have PG Atlas operational before the first Q2 voting round, providing metric context that voters and reviewers can reference. PG Atlas v0 is scoped for a single-machine deployment. Deliverables include:
Data Ingestion Pipeline: Build the ingestion layer to populate the dependency graph and contributor statistics from SBOM submissions, registry crawling, and git logs.
Storage & Data Model: Implement a two-level PostgreSQL data model with NetworkX for graph analytics, supporting project and repository relationships.
Metric Computation Engine: Develop algorithms to compute criticality scores, pony factors, and adoption signals, materialized for fast API/dashboard reads.
API Layer: Create a public, read-only REST API to expose PG Atlas metrics for integration with dashboards and external tools.
Dashboard: Build a user-friendly dashboard to visualize metrics, dependency graphs, and project-level insights.
Deployment: Deploy PG Atlas v0 as a single-machine system with <$100/month operational costs, ensuring scalability for future iterations.
All of this will be built as free open-source software from the beginning.
$150.0K
This project has been selected as the first concrete initiative in a broader effort to explore enhanced decentralization for the Stellar Community Fund. The SCF Public Goods Award soft-launched in June 2025 with intentionally centralized aspects to validate the award structure. After running several rounds, this structure has proven itself, and we are now ready to take the first step towards broader community participation.
PG Atlas supports the first Public Goods Award round in Q2 (April) with an updated structure. Initially, it will be used by eligible public goods maintainers and all SCF Pilots to ensure that critical ecosystem components can receive sufficient funding. Later in the year, we expect to trial the first round with delegated community voting, similarly to the existing Build Award (Open track) process.
19% of budget for first tranche (2 weeks)
Create a dedicated SCF Governance organization on Tansu. This is the on-chain space where eligible PG Award proposals will be submitted, discussed, and voted on. Projects applying for awards don't need to be registered on Tansu themselves—the governance space is independent.
Acceptance Criteria:
The SCF Governance space has a Soroban Domain and is visible on Tansu.dev
There is a proposal template for PG Award applications
It is clearly documented how the SCF Governance space will be used in the award process
Budget: $2,000
Set up the PG Atlas component repositories and continuous integration pipelines under the SCF Public Goods Maintenance GitHub organization. This is the prerequisite for all parallel development work on the backend, ingestion, and dashboard.
Acceptance Criteria:
Component repositories for the PG Atlas backend (API + ingestion) and dashboard are created and publicly accessible under the SCF Public Goods Maintenance org
Each repository has a passing CI pipeline (linting and tests) on the main branch
Each repository has a README with local development setup instructions
Each repository has a FOSS license to ensure code reusability
Budget: $3,000
Provision a hosted PostgreSQL instance and apply the two-level data model: Projects, Repos, ExternalRepos, Contributors, depends_on edges, and contributed_to edges. This is the storage foundation that all ingestion pipelines write to.
Acceptance Criteria:
A hosted PostgreSQL instance is running and accessible to the development team
The full schema is applied and version-controlled as a migration script
The migration script is documented and can be applied from scratch to reproduce the schema
Budget: $5,000
Bootstrap the FastAPI application with a health endpoint and a SBOM webhook receiver. The webhook is the entry point for project teams submitting SBOMs—it accepts, validates format, and queues submissions for downstream processing (A8).
Acceptance Criteria:
The FastAPI application is deployed and reachable at a live URL
GET /health returns a valid response
POST /ingest/sbom accepts a CycloneDX SBOM payload, validates its format, and returns 202 Accepted for valid submissions
Submissions with invalid or missing GitHub Action signatures are rejected with an appropriate error response
Budget: $9,000
Publish a GitHub Action that project teams add to their CI pipelines. The action generates a CycloneDX SBOM and submits it to the PG Atlas webhook. Early release gives SCF public goods maintainers maximum lead time to onboard before the Q2 voting round.
Acceptance Criteria:
The GitHub Action is published and installable from a public repository
The action generates a valid CycloneDX SBOM and submits it to the configured PG Atlas endpoint
Usage documentation and an example workflow YAML are published
The action has been announced to SCF public goods maintainers
Budget: $6,000
Build a script that seeds the Projects table from OpenGrants, the DAOIP-5-compatible registry of SCF-awarded projects. This provides the initial set of known public goods and their dependent SCF projects as starting nodes for the dependency graph.
Acceptance Criteria:
The bootstrapper fetches SCF project data from OpenGrants and populates the Projects table
The Projects table contains >150 known Stellar/Soroban projects with display_name, git_org_url, and activity_status populated
The bootstrapper is documented and runnable as both a one-off script and a scheduled job
Budget: $4,000
33% of budget for second tranche (2 weeks)
Integrate SCF's existing NQG (Neural Quorum Governance) scores as voting weights in Tansu. Currently, NQG scores are calculated and stored in the stellar-community-fund-contracts. Tansu already supports badge-based weighted voting—the work here is bridging Tansu's weight system to read from dynamic/changing NQG scores.
Tansu's voting infrastructure supports two integration paths: token-based (locking collateral proportional to assigned weight) or badge-based (mapping NQG scores to on-chain badges). Both are feasible with modest contract work. The choice depends on UX and governance preferences—the working group will finalize this during implementation.
Note on anonymous voting: Tansu already supports anonymous voting using BLS12-381 Pedersen commitment schemes. This is available out of the box for the PG Award: the SCF space maintainer can inspect votes (comparable to current process), while individual voter choices remain hidden from other participants. No additional development is needed for this capability.
Acceptance Criteria:
Smart contract integration between NQG score source and Tansu voting weights is implemented
Frontend updates display NQG-weighted voting power
Integration is deployed on testnet and is verified to work
Budget: $15,000
Build crawlers for npm, crates.io, PyPI, and the Go proxy that populate the dependency graph from public package registries, starting from curated Stellar/Soroban root packages. Once the graph is populated, compute the active subgraph projection—the set of repos reachable from at least one active project leaf—which is the prerequisite for criticality scoring in Tranche 3.
Acceptance Criteria:
Crawler(s) for npm, crates.io, PyPI, and Go proxy have completed at least one full run
The dependency graph contains >100 Repo/ExternalRepo nodes with depends_on edges marked inferred_shadow
The active subgraph projection produces a correct, queryable set of active nodes
Crawlers are idempotent and safe to re-run without duplicating nodes or edges
Budget: $16,000
Build the git log ingestion pipeline that parses contributor history for the git repositories in the Repos table. This populates Contributor vertices and contributed_to edges, providing the raw data for pony factor computation in Tranche 3.
Acceptance Criteria:
The git log parser runs against all Stellar public goods repos, and on other (SCF project or external) repos as desired
Contributor vertices and contributed_to edges (with commit counts, first/last commit dates) are populated in the database
Repo.latest_commit_date is updated for all processed repos
The parser handles repos with no commits or inaccessible URLs gracefully (logged, not fatal)
Budget: $10,000
Implement the downstream processing pipeline for queued SBOM submissions: schema validation, dependency extraction, repo and edge upserts, and NetworkX graph reload. This closes the loop between the webhook receiver (A3) and the live graph. SBOMs submitted by early-adopting projects will be reflected in graph queries once A8 is complete. See the Ingestion specification for the full processing logic.
Acceptance Criteria:
Queued SBOM submissions are validated against the CycloneDX schema; malformed submissions are rejected and logged
Valid SBOMs are processed end-to-end: the submitting Repo is upserted, declared dependency edges are created or updated with verified_sbom confidence
The NetworkX graph is invalidated or reloaded after each processed SBOM
End-to-end verified: a test SBOM submission results in observable Repo and edge changes in the database
Budget: $8,000
48% of budget for third tranche (3 weeks, with most of the work started earlier)
Build NQG scores as dynamic, soulbound NFTs following the SEP-50 spec for Freighter wallet compatibility. Each SCF Pilot gets a visible, on-chain representation of their governance reputation that updates as their NQG score changes.
This has value beyond the PG Award: any Stellar ecosystem project could leverage this trust signal (e.g., Soroban Security already uses Discord-based Pilot verification for audit report submissions; an on-chain credential would be a direct improvement).
Acceptance Criteria:
Smart contract for soulbound dynamic NFT issuance and updates is implemented
Art/design for status visualization is completed
Freighter integration testing is performed and documented
Comprehensive documentation for the NFT system is published
Budget: $15,000
Compute and materialize the two primary impact and risk metrics—criticality scores and pony factors—at both repo and project level. Criticality (transitive active dependent count) builds on the active subgraph from A6; pony factor builds on the git contributor data from A7. These are the headline signals that are displayed on the dashboard and can later be used in the Metric Gate. See the Metric Computation specification for the full algorithms.
Acceptance Criteria:
Criticality scores are computed for all repos in the active subgraph and materialized to repos.criticality_score
Project-level criticality is aggregated and materialized to projects.criticality_score
Pony factors are computed from contributed_to edge data and materialized to repos.pony_factor and projects.pony_factor
A batch recompute runs on schedule and is triggered by significant graph changes (e.g., new SBOM ingestion)
Budget: $9,000
Fetch and store off-chain adoption data—registry download counts (last 30 days), GitHub stars, and forks—for all repos in the Projects table. These supplement criticality and pony factor as a third signal for voters and reviewers.
Acceptance Criteria:
Download counts are fetched from npm, crates.io, and PyPI for all known packages and stored in repos.adoption_downloads
GitHub stars and forks are fetched and stored in repos.adoption_stars and repos.adoption_forks
Adoption signals are aggregated to project level in projects.adoption_score
A periodic refresh job keeps adoption signals up to date
Budget: $5,000
Build the full public, read-only REST API that exposes all PG Atlas data to the dashboard, Tansu voting context, and community tools. Includes an auto-generated TypeScript SDK for easy consumption by external integrations.
Acceptance Criteria:
Core endpoints are live and return real data: /projects, /projects/{id}, /repos, /repos/{id}, /repos/{id}/dependents, /repos/{id}/dependencies, /scores, and graph export
OpenAPI spec is auto-generated and can be interactively tested at /docs
Rate limiting (100 req/min per IP) is enforced
A TypeScript SDK is generated from the OpenAPI spec, published, and documented with usage examples
Budget: $15,000
Build the public, zero-auth React-based dashboard that makes PG Atlas data browsable for voters, maintainers, and community observers. The dashboard consumes the REST API exclusively.
Acceptance Criteria:
The dashboard is publicly accessible at a live URL with no login required
The landing page displays an ecosystem summary: total active projects, top critical PGs, and a risk distribution overview
The searchable leaderboard shows projects sortable by criticality, pony factor, and adoption, with risk flags (e.g., pony factor = 1 highlighted)
Project detail pages show score breakdowns, dependent and dependency lists, and contributor statistics
An interactive dependency (sub-)graph visualization is accessible from project detail pages
Budget: $15,000
Put all PG Atlas components into production with automated scheduling, monitoring, and backups, per the operations specification.
Acceptance Criteria:
Scheduled jobs are running: registry crawls (weekly), git log refresh (periodic), and metric recomputes (scheduled batch + triggered on SBOM ingestion)
Health monitoring is configured: the /health endpoint is monitored externally with alerting on failure
Error tracking (Sentry) is active for the API and ingestion services
Database backups are automated (daily pg_dump to a remote location)
Budget: $10,000
Establish the mechanisms for the community to report graph errors and propose project additions, and complete an initial data quality pass before the Q2 voting round opens.
Acceptance Criteria:
Issue templates for reporting graph corrections and proposing new project additions are published in the GitHub repo
Known Stellar/Soroban public goods are present in the graph with plausible metric values
The first correction cycle has been initiated: community feedback is being received, reviewed, and reflected in the graph
Budget: $3,000
Alex Olieman (SCF Pilot) aka convergence is the co-founder of Stellarcarbon, launched during Meridian 2025 with three SCF Build Awards. Active in Stellar as a dev since 2020, he contributes to FOSS public goods, including graph systems analyzing millions of parliamentary interactions across countries. He led enterprise knowledge graph development and built DBpedia infra still in production—"a pillar of the Stellar Community Fund" (iykyk). [LinkedIn]
Pamphile Roy (SCF Pilot) aka tupui is a Principal Engineer at The Aha Company. In Scientific Python, he maintains SciPy (2M+ downloads) and SALib as FOSS. Active in Stellar for two years, he contributed docs, two SEPs, and served as SCF delegate. Pamphile shipped Soroban public goods on mainnet: Tansu, and the official Stellar merch shop, ChimpDAO, both SCF-supported. [LinkedIn]
Jay Gutierrez, PhD, is a computational systems scientist specializing in graph-based intelligence. He's operated knowledge graphs with 30M+ nodes using network science like k-core decomposition and centrality analysis. His expertise covers algorithms (NetworkX, igraph), databases (Neo4j), and pipelines (GraphRAG, LangGraph) in Python for scalable risk quantification in public goods. [LinkedIn]
Jay Gutierrez
Alex Olieman
Tupui
No other submissions.