Submission Review Criteria

Incoming submissions are reviewed in detail and only those that can check all the below requirements, and don’t fall under any ineligible category, will be considered for selection. Also, make sure that your submission has all the context a reviewer may need and doesn’t require any additional context: the panel does not take any other information into account other than what is mentioned on the submission.

Category Specific Submission Criteria

You can find more specific eligibility criteria for each project category below:

(End-User) Applications

This category is for applications focused on end-users, such as wallets, marketplaces, and more.

Ecosystem Goals:

  • Support projects that demonstrate the potential for using Stellar to improve on the way things are done today (e.g. faster, cheaper, fairer, more sustainable).

  • Encourage projects with broad audiences that leverage a simplified user experience to attract more users.

  • Support projects that make decentralized financial services more accessible to a broader audience.

  • Create applications that reach significant adoption levels and in that way serve as a showcase for others, for example VC’s in the blockchain space.

  • Promote the development of applications that prioritize user security and privacy, incorporating features such as multi-signature wallets, secure key management, and transparent auditing to enhance trust in the Stellar ecosystem.

  • Encourage the creation of end-user applications that are interoperable with other blockchain networks and traditional financial systems.

  • Encourage applications that strengthen the reputation of Stellar as a force for good (e.g. international aid, sustainable development). Stand out against the web3-backdrop of projects that purely encourages speculation and finance.

Eligibility Criteria:

  • Team should provide sufficient evidence of use-case validation. This may include:

    • (Significant) user traction;

    • User interviews/customer discovery;

    • Target market and competition analysis;

    • Appropriate demoing to target users.

  • The integration of blockchain should be appropriate for the use-case and intended users. Using Stellar/Soroban should enable or improve a service rather than over-complicate it.

  • The team needs to demonstrate how they’ll focus on their Stellar/Soroban integration. Show us how much of your team capacity will be dedicated to the Stellar functionality and how your users will benefit from the integration.

  • The team must demonstrate a comprehensive understanding of their target market and present a compelling, well-structured pitch deck.

  • Teams provide a high level technical architecture that demonstrates capability and readiness to build

  • Evidence of competition analysis and clear indication of how their solution differs from competitors in the space.

Financial Protocols

This category is for financial protocols such as AMMs, DEXes, Collateralized Stablecoins, and more.

Ecosystem Goals:

  • Support projects likely to attract liquidity and therefore end-users to the ecosystem.

  • Support projects that reinforce the Stellar network's position as the ideal blockchain for financial institutions (WisdomTree, Franklin Templeton, etc.).

  • Encourage the development of innovative DeFi protocols and services that leverage the Stellar network's unique capabilities

  • Support projects that enable the creation of sustainable on-chain yield through transparent and risk-mitigating tools. This primarily involves the tokenization of cash-flow positive real-world assets (money-market funds, tbills, etc.) and DeFi financing solutions for real-world lending (private credit, etc).

  • Create high quality software and assets that can be used broadly in the ecosystem and are interoperable with the rest of the ecosystem.

Eligibility Criteria

  • Team should provide evidence of use-case validation. This may include:

    • Market research done on the model;

    • Usecase contextualized within the Stellar Ecosystem specifically;

    • User research;

    • Explain how the model has been successful in other ecosystems.

  • Solutions should be created by teams with experience in trading systems. This is a heavily regulated industry, so it’s better if the team understands that.

  • The proposal must clearly articulate the value proposition of the financial protocol and how it differentiates itself from existing solutions in the market. This should include a competitive analysis that highlights unique features, advantages, and how the protocol addresses specific pain points or gaps in the current ecosystem.

Infrastructure & Services

This category includes Security, Data, RPCs, Oracles, Indexers, Anchors, and Custodial Services.

Ecosystem Goals:

  • Ensure builders have all of the tools they need to build, deploy, and analyze on Stellar.

  • Improve data accessibility, indexing, and transparency for better insights and analytics within the Stellar ecosystem.

  • Encourage tools and dashboards that provide real-time insights into the health and performance of the Stellar network, including node status, transaction throughput, and latency.

  • Encourage the development of scalable cloud infrastructure solutions that make it easier to deploy, manage, and maintain Stellar nodes, reducing the barrier to entry for new participants in the network.

  • High availability of easy to access Stellar data, so that builders and users can understand how Stellar applications are being used.

Eligibility Criteria:

  • Evidence of use-case validation. This may look like:

    • Integration with at least one top 20 cryptocurrency (e.g., BTC or ETH) listed on CoinMarketCap.

    • Existing user traction

    • Experience in the Stellar Ecosystem

  • Submissions should outline proposed Service Level Agreements (SLAs) and key performance metrics, such as uptime, latency, and throughput, to set clear expectations for service reliability and performance.

  • Evidence of competition analysis and clear indication of how their solution differs from competitors in the space.

  • Indication that teams have looked into Stellar and understand the tech stack.

Developer Tooling

This category is for developer tooling and resources including IDEs, reusable contract building blocks, security and testing tooling, governance tooling, and more.

Ecosystem Goals:

  • Provide tools and resources that enable developers to build, test, and deploy applications more efficiently on the Stellar network.

  • Maximize collaboration between existing and future developer tools to ensure they remain relevant and do not become obsolete or redundant.

  • Reduce duplications of effort in building developer tooling.

  • Have as much “sustainable tooling” as possible. Developer tools should have long-term, core maintainers and ways for community members to clearly contribute towards the repo.

  • Increase the surface area of developer tooling to funnel new developers into the ecosystem, rather than just serving existing devs.

Eligibility Criteria:

  • Projects must be open source.

  • Projects do not need a business case, but need developers who are users.

    • If you are building Github, you are within end-user applications. If you are building git, you are within developer tooling.

  • There should be a clear plan provided for maintainability.

  • Submissions should outline specific, measurable impact metrics they aim to achieve within the first 6 months of deployment, such as the number of active users, number of transactions processed, or amount of value transacted.

  • The project should demonstrate scalability and adaptability to future network changes or upgrades, ensuring that the tool or resource remains useful and relevant as the Stellar ecosystem evolves.

  • The project should be able to show why their tooling is actually needed in the Stellar ecosystem.

  • The code should be built in the open, and allow for the community to report issues, submit bug fixes, etc. They should have a plan for long term maintainability.

  • If a solution for the problem already exists, then the submission should contain reasoning on why their proposed solution is better/unique/different.

    • Ex: If they propose an online editor, then the submission should compare itself to Okashi or codespaces.

Important Note for Issuers of Fiat-Backed Tokens:

If your Project already issues or plans to issue a stablecoin or digital asset backed by fiat currency as a part of your SCF submission, you will need to complete a Stellar Info File, and as per the requirements in the Stellar documentation, it must include a URL to an attestation or other proof, evidence, or verification of sufficient reserves, such as a third-party audit.

Important Note for Recipients of other Funds, Grants, or Investments from SDF:

  • Entities in which either the Matching Fund or Enterprise Fund have invested are not eligible to receive an SCF Award.

  • Recipients of any currently outstanding Research & Development Grant and/or Academic Research Grant are not eligible to receive an SCF Award unless and until such recipient has submitted all required deliverables and fulfilled all obligations under their respective Grant Agreement(s).

  • Recipients of any currently outstanding Marketing Grant, Currency Support Grant, and Ecosystem Infrastructure Grant, will not be eligible to receive an SCF Award for any project or deliverable that falls within the scope, whether directly or indirectly, of their respective Grant Agreement(s).

  • Recipients of prior SCF Awards are permitted to resubmit a new Project to a subsequent SCF Round, but they will be required to show that their previously awarded Project has achieved significant progress on the goals set forth in their previous submission (at SDF’s discretion).

Last updated