Submission Criteria
Only submissions that meet all required criteria and fall within SCF eligibility will be considered for funding. Reviewers assess each application based solely on the information provided in the submission.
No external materials are considered.
Be sure your submission is complete and self-contained. Include everything a reviewer needs to evaluate your project.
Prescreen: What Happens Before Panel Review
Before your SCF Build application is reviewed by the full panel, it goes through an internal prescreen.
This step isn’t about judging the strength of your idea. It’s about ensuring your submission is complete, reviewable, and ready.
Why We Do It
Prescreening helps:
Save reviewers time by filtering out submissions with basic issues
Ensure every application that reaches the panel is complete and clear
Give applicants a chance to fix small mistakes before they become blockers
What We're Looking For
During prescreening, the SCF team does a check for:
Vague or missing deliverables (or deliverables that don't have a specific budget amount associated with them).
Inflated or unbalanced budgets
Ineligible expenses (like marketing, token giveaways, etc.)
Missing technical details or architecture
Deliverables that don’t align with SCF’s requirements
(Integration Track) A present, concrete, and credible final-tranche metric commitment — not omitted, vague, trivially low, or unrealistically high.
In some cases, the SCF team will reach out with suggested edits so you can improve your submission before it’s sent to the panel.
Prescreening is your last opportunity to fix basic errors. After that, the panel reviews exactly what’s in your application and nothing more.
Criteria for SCF Build Application Panel Review
Your application must satisfy all of the following:
Participant Eligibility
You must meet all Participant and Submission Eligibility Requirements, as well as any Category-Specific Eligibility or Jurisdiction-Specific Restriction that may apply.
Product Readiness & Traction
Your project must demonstrate product–market fit, either through:
Significant user traction, or
A clearly validated need identified by a team or individual with relevant experience in the Stellar ecosystem.
Traction may be on Stellar, another chain, or off-chain, but must be verifiable in-submission.
Submission Quality
Your submission must be:
Technically detailed and well-structured
Clear and easy to understand
Comprehensive: reviewers should not need to guess or follow up
Stellar Use Case & Technical Integration
Your proposal must include:
A clear use case for Stellar
A technical explanation of how Stellar will be integrated
A complete architecture outline showing how your system works
Build Readiness
You should be ready to begin development as soon as the award is granted. This includes:
A fully defined roadmap and technical plan
Developers on your team with experience in the relevant tools/languages
Ideally, plans to leverage existing ecosystem tools and solutions rather than building from scratch.
Stellar Relevance
Stellar must be used to meaningfully improve core features, not as a superficial integration, or for data storage.
Open Source Plan (for Smart Contracts)
If your project includes smart contracts, your application must include a clear plan to open-source them.
Budget Alignment
Your proposed budget must:
Only cover development costs for the Stellar-integrated components
Be reasonable in light of your project’s scope, stage, and potential impact
Follow the SCF Budget Guidelines
Tranche Structure
Your application must include three tranches of deliverables. The final tranche should be your Mainnet launch. In certain cases, jurisdiction-specific restrictions may require a modified tranche structure (for example, where deployment is limited to testnet). If this applies to your project, the SCF team will provide guidance on how to structure your tranches before you submit. Define your own path with your other deliverables, but make sure milestones make sense for your proposed build. One suggestion is to organize your tranches as:
Tranche 1: MVP
Tranche 2: Testnet
Tranche 3: Mainnet
Each tranche must contain:
Feasible, well-defined deliverables
Sufficient detail and realistic timing
How much each deliverable will cost
How reviewers will be able to check completion of each deliverable
Integration Track — Final-Tranche Metric Commitment
Integration Track submissions must also include a final-tranche onchain metric commitment:
The metric type — NAV, cumulative payment/transaction volume, or an equivalent onchain measure appropriate to the integration.
The proposed threshold and the measurement window over which it will be assessed.
The onchain footprint you will register at award time so the metric is attributable to your product, for instance Soroban contract IDs, asset issuing accounts, app-operated wallets, and sponsored accounts.
The panel ratifies or adjusts your proposal during review. A modest, credible threshold that demonstrates real usage is expected — not an aggressive growth target.
Tranche #2 Threat Model and Monitoring Plan Requirements
The most effective time for projects to identify potential security issues and enable future success with monitoring and observability is during the planning and building phase of the project. Toward that end, we are adding a requirement for a threat model and a “monitoring plan” into the tranche 2 requirements. This requirement helps teams identify issues earlier in the lifecycle and create observability metrics (emissions, triggers, etc) that can be used for monitoring in the future.
Similar to the STRIDE model, some project teams may not be familiar with building monitoring plans. That is why we have developed similar training materials to what we did for the STRIDE model documentation, but with the monitoring plan using the output of the threat model. Documentation will guide you, the project team, from inception, through building a threat model, to building a corresponding monitoring plan.
This documentation provides a framework for builders or users in the ecosystem to plan out their monitoring requirements:
Ecosystem Value & Differentiation
Your project must:
Provide clear value to the Stellar ecosystem
Be unique or meaningfully differentiated from other available solutions
Additional Requirements
For Fiat-Backed Token Issuers
If your project issues (or plans to issue) a fiat-backed digital asset:
You must complete a Stellar Info File
It must include a URL to a third-party audit or other proof of sufficient reserves, per Stellar documentation
For Teams Receiving Other SDF Funding
Entities funded through the Matching Fund or Enterprise Fund are not eligible
Teams with outstanding Research or Academic Grants must fulfill all obligations before applying
Teams with active Marketing, Currency Support, or Infrastructure Grants cannot seek funding for overlapping work
Teams that received a prior SCF Build Award may apply again, but must show significant progress on the previous project—at SDF’s discretion.
Last updated