Proposal Track: SCF Infrastructure Grant (Build Award)
Status: Phase 0 shipped (v0.1.0) · Phase 1's Soroban subscription, ABI registry client, and cursor persistence have since shipped too · Requesting funding for the remaining Phase 1 milestones (discriminated union refinement, starter boilerplates, v1.0 stability pledge)
Repository: https://github.com/determined-001/orbital_stellar
License: MIT
Last updated: 2026-07-06
- Summary
- Problem
- Solution
- Track record - Phase 0 (shipped)
- Phase 1 - Production-grade
v1.0 - Why Stellar needs this funded now
- Risks and mitigations
- Budget
- Sustainability after Phase 1
- Team
- Roadmap context (out of scope)
- Asks of the SCF reviewer
- References
Orbital is the open-source SDK layer Stellar developers reach for when they need real-time event subscriptions, signed webhook delivery, and React integration - the primitives every team currently re-implements from scratch on top of Horizon SSE and Stellar RPC.
Four MIT-licensed packages, designed to be composed and published to npm under the @orbital-stellar scope with no vendor lock-in:
| Package | Role |
|---|---|
@orbital-stellar/pulse-core |
Event engine - Horizon + Stellar RPC (Soroban) subscription, normalized typed events, reconnection, cursor persistence |
@orbital-stellar/pulse-webhooks |
HMAC-signed webhook delivery, retry with durable queues, SSRF hardening, edge-runtime verification |
@orbital-stellar/pulse-notify |
React hooks (useStellarEvent, useContractEvent, useStellarPayment, useStellarActivity) |
@orbital-stellar/abi-registry |
Soroban ABI client, schema helpers, registry publisher interface |
Phase 0 (foundation) shipped as v0.1.0 - full classic operation taxonomy, edge-runtime verification, React hooks, reference composition. Since then, three of Phase 1's six milestones (M1 Soroban subscription, M2 ABI registry client, and the cursor-persistence half of M4) have also shipped. This proposal funds the remaining Phase 1 work: discriminated union refinement (M3), starter boilerplates (M5), and the v1.0 stability pledge (M6) - the milestone at which any Stellar team can build on Orbital with a documented semver contract.
Stellar's official APIs give developers the raw firehose:
- Horizon SSE drops the connection on idle, requires backoff, has no replay, and exposes raw operations rather than application-shaped events.
- Stellar RPC keeps only ~7 days of Soroban event history and has no native subscription model.
- Webhooks are not part of the platform - every project rebuilds HMAC signing, retry, SSRF guards, and edge-runtime verification from scratch.
- React integration does not exist - every dashboard rebuilds SSE plumbing and lifecycle management.
The cost: every Stellar team - anchors, payment apps, DEX frontends, wallet teams - spends weeks building infrastructure that should be a pnpm add. There is no shared, auditable, maintained primitive.
The competitive landscape, accurately: QuickNode shipped basic Stellar webhook support in Q1 2026 - generic multi-chain DX without a native Stellar mental model, no React SDK, no SSE streaming interface, no edge-runtime verifier. Moralis offers early-access Stellar streams as part of its multi-chain warehouse, not as a low-latency event-delivery service. Sorobanhooks ships Soroban-only webhooks with no classic-operation coverage and no SDK layer. The gap Orbital fills is not "events on Stellar" - it is a Stellar-native, MIT-licensed SDK family that covers the full operation taxonomy with edge-runtime verification and first-class React hooks in one coherent surface.
Orbital ships the primitives once, openly, with a multi-year commitment to keep the SDK surface stable and grow it in lockstep with the network (Soroban events, the decoding standard, future SEPs).
The system is three planes sharing one vocabulary - the normalized event: a subscription plane (pulse-core) that connects to Stellar and routes typed events to per-address Watcher subscribers; a delivery plane (pulse-webhooks) that signs and POSTs events with retry, timeout, and SSRF safety; and a consumption plane (pulse-notify) that opens an EventSource from a browser and re-renders React components on each event. Each plane is independently installable and independently composable. The reference composition that powers the on-page demo at the marketing site lives in a single Next.js route handler - about 50 lines of glue.
Full system diagrams, lifecycle sequence, and trust-boundary analysis live in docs/ARCHITECTURE.md.
The SDKs are MIT - free for commercial and open-source use. Stellar developers should not pay a per-call fee to consume their own ledger's events. Orbital follows the Vercel/Clerk model: the SDK family is open and free; a separately-built closed Cloud product (out of scope for this grant) handles the multi-region orchestration and persistence that teams who do not want to run their own infrastructure pay for. No feature in this proposal is contingent on the Cloud product, and no SDK capability is gated behind it.
This is deliberately not the Supabase/MongoDB model - Orbital does not open-source the server, because doing so creates asymmetric infrastructure cost exposure and historically destroys the grant-funded project's ability to keep maintaining the OSS at scale.
Phase 0 is complete and released as v0.1.0. Independently verifiable on the public repository:
| Deliverable | Status |
|---|---|
| Classic operation event streaming via Horizon SSE | ✅ Shipped |
| Full classic operation taxonomy: payments, account create/merge/bump-sequence, trustlines (change/allow/set_flags), DEX offer lifecycle, claimable balance lifecycle, liquidity pool deposit/withdraw, manage_data | ✅ Shipped |
| HMAC-signed webhook delivery with retry, exponential backoff, concurrent-retry caps | ✅ Shipped |
| Edge-runtime webhook verification (Cloudflare Workers, Vercel Edge) using Web Crypto API | ✅ Shipped |
React hooks (useStellarEvent, useStellarPayment, useStellarActivity) |
✅ Shipped |
| SSRF hardening (private IP range blocks, DNS-rebinding defense) | ✅ Shipped |
Reconnection with AWS Full Jitter backoff and rate-limit handling (engine.rate_limited on HTTP 429) |
✅ Shipped |
| Custom Horizon URL support (self-hosted node / regional mirror / futurenet) | ✅ Shipped |
| Reference composition consolidated into a single Next.js route handler - one runtime to self-host, not two | ✅ Shipped |
Public marketing + documentation site (apps/web) with sandboxed demo API routes |
✅ Shipped |
| Testnet + mainnet support | ✅ Shipped |
| CI matrix (Node 20, 22), CodeQL static analysis, Dependabot, conventional commits, PR template | ✅ Shipped |
Evidence trail:
CHANGELOG.md- fullv0.1.0release notes with Added / Changed / Fixed / Security / Impact sections.docs/ARCHITECTURE.md- system diagrams, component inventory, lifecycle sequence, trust boundaries.PROGRESS.md- Phase 0 completion snapshot.ROADMAP.md- multi-year phase plan.- Per-package READMEs:
pulse-core,pulse-webhooks,pulse-notify,abi-registry. - Test suites: 500+ tests in
pulse-core, 180+ tests inpulse-webhooks, all green in CI.
Phase 1 brings Orbital from "useful prototype" to a stability-pledged v1.0 that teams can build production systems on. Six concrete deliverables. M1, M2, and the cursor-persistence half of M4 have shipped since this proposal was first drafted; M3, M5, and M6 remain the funded scope.
Subscribe to smart contract events by contract ID and topic filter via Stellar RPC. Normalized into the same NormalizedEvent taxonomy as classic operations, via engine.subscribeContract({ contractId, topics }).
Done when: A test subscribing to a deployed Soroban contract on testnet receives a typed event payload within 2 ledgers of emission. - met; see packages/pulse-core/test/SorobanSubscriber.*.test.ts and the integration test suite.
Auto-decode Soroban event payloads into typed, human-readable JSON using the @orbital-stellar/abi-registry client. Solves the "raw bytes" problem that makes Soroban events painful to consume today.
Done when: A registered contract's events are fully typed in the consumer's TypeScript autocomplete without manual decoding. - met; EventEngine enriches contract.emitted with typed decodedData when an AbiRegistryClient is configured.
Narrow NormalizedEvent types so switch (event.type) produces exhaustive type narrowing in TypeScript strict mode.
Done when: A switch over event.type with no default clause produces a TypeScript error if any event type is unhandled.
Pluggable durable adapters so consumers can implement crash-resilient streams and webhook replay. Cursor persistence (CursorStore: memory, file, Postgres, Redis, S3) has shipped in pulse-core; durable webhook retry queues (RetryQueue: memory, Redis, SQS) have shipped in pulse-webhooks. Remaining under this milestone: hardening and documenting the replay story end-to-end (see packages/pulse-webhooks/src/cli.ts's orbital dlq replay command).
Done when: Killing the worker process mid-stream and restarting it does not lose or duplicate events when configured with a Postgres cursor adapter. - met; see packages/pulse-core/test/EventEngine.sorobanCursorResume.test.ts and test/integration/cursorResume.test.ts.
Three reference projects: orbital-next-starter, orbital-express-starter, orbital-anchor-starter. Demonstrate the SDK in production-shaped repos a Stellar team can fork in 5 minutes.
Done when: Each starter is published, deploys to Vercel/Railway free tier, and is documented end-to-end on the marketing site.
All four packages are already published under @orbital-stellar/ on npm. Remaining under this milestone: a documented stability contract - no breaking changes within v1.x without a 6-month deprecation window.
Done when: pnpm add @orbital-stellar/pulse-core works - met - semver policy is documented in STABILITY.md, and a v1.0 release is tagged on GitHub - both remaining.
Soroban window: Stellar RPC keeps ~7 days of event history. Every project that wants Soroban analytics, indexing, or webhooks needs an event consumer running continuously. Funding the SDK now means every project that ships during Soroban's growth phase reaches for the same primitive - increasing ecosystem interoperability and reducing duplicated infrastructure cost across the network.
Standards leverage: Phase 1 lays the groundwork for Phase 2's first SEP submission - formalizing the event normalization format so other implementations (Rust, Go, Python clients) can interoperate with Orbital-shaped events. SCF funding the reference TypeScript implementation makes the future SEP carry weight.
Competitive timing: QuickNode added basic Stellar webhooks in Q1 2026 - a generic multi-chain product. The window to establish a Stellar-native, edge-runtime, React-first SDK as the developer default is the next 12 months, before generic multi-chain DX hardens around Stellar. No Stellar-native alternative covers the three primitives (typed normalization + edge verification + React) in one coherent SDK family. Orbital does, today, in v0.1.0.
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Solo-maintainer bus factor | High | High | The grant funds a contributor ladder. Phase 0 already shipped the Stellar Wave Program issue plumbing (150 pre-planned issues with complexity-tier rewards) and a contributors-table workflow. Target: ≥3 sustained external contributors with merged PRs by Phase 1 close. |
| QuickNode achieves feature parity within 12–18 months | Medium | Medium | Moat is engineering depth + standards authorship, not feature count. Orbital's normalized-event format becomes a Phase 2 SEP submission; once ratified, QuickNode either conforms (validating Orbital) or diverges (fragmenting Stellar). MIT licensing + edge-runtime + React hooks remain hard to replicate inside a generic multi-chain product. |
| Soroban event API churn | Medium | Low | The Soroban subscriber is a pluggable source feeding the same normalization pipeline; upstream churn is isolated to packages/pulse-core/src/SorobanSubscriber.ts and SorobanRpcClient.ts (per docs/ARCHITECTURE.md §10) and does not propagate to the public NormalizedEvent union. |
| Horizon → Stellar RPC migration timeline | Medium | Medium | CoreConfig.horizonUrl already supports custom backends; the RPC subscriber shipped as M1, giving consumers a typed migration path before Horizon's deprecation horizon. |
| Webhook secret leak in downstream consumer code | Low | High | WebhookDelivery enforces HMAC-SHA256 with timing-safe comparison and SSRF block-lists by default; receivers use verifyWebhook (Node) or verifyWebhookEdge (Web Crypto) which both fail closed. See docs/ARCHITECTURE.md §8 for the full trust-boundary table. |
| Grant-fund exhaustion before Phase 1 milestones complete | Low | Medium | Remaining milestones (M3, M5, M6) are independently shippable. M1, M2, and M4's cursor half are already delivered outside grant funding; M3 and M6 alone would close out a stability-pledged v1.0 even if M5's starter boilerplates slip. |
Total Phase 1 ask: $30,000 USD, milestone-released. Six months solo development plus modest mainnet infrastructure for testing.
| Line item | Allocation |
|---|---|
| Engineering - solo founder, 6 months part-time at recoverable rate | $22,000 |
| Mainnet testnet RPC node (Hetzner, $50/mo × 6) - required for M1 testing | $300 |
| Soroban contract deployment + signing fees on testnet for M2 ABI work | $200 |
| Documentation site hosting + CDN | $0 (Vercel free tier) |
| Database + auth for M5 starter boilerplates | $0 (Neon + Auth.js free tier) |
| Buffer for testnet-to-mainnet validation, security audit prep, dependency upgrades | $7,500 |
Funding model rationale: Orbital's commercial sustainability comes from a separately-built closed Cloud product, not from grant-dependence. SCF funding is requested to accelerate Phase 1 delivery while the founder is unfunded, not as the project's long-term funding mechanism. Once Phase 1 ships and Cloud begins generating revenue, the SDK family is self-sustaining without further grant support.
The SDKs remain MIT and free indefinitely. Maintenance funding comes from:
- Orbital Cloud - a separate closed-source managed runtime built on these SDKs, billed in USDC-on-Stellar (dogfooding the SDKs). Out of scope for this grant; mentioned only to explain why the OSS is sustainable without recurring grant ask.
- Drips network donations - Orbital is registered for Stellar Wave Program issue rewards, with
Stellar Wave–tagged issues pricing in 100/150/200-point complexity tiers. - Future SCF Adopt/Audit grants - for specific Phase 2/3 deliverables (SEP draft,
orbital codegen,@orbital-stellar/anchor-sdk, security audit).
The grant funds the milestone, not the team's salary in perpetuity.
Solo founder (reachable at 210902543@live.unilag.edu.ng) - based in Lagos, Nigeria. Currently unfunded. Phase 0 was built in approximately 5 weeks of evenings-and-weekends work on the public repository - see commit history for cadence and quality signal.
Phase 1 will be delivered by the same founder with the same commit transparency. No subcontractors. No undisclosed contributors.
Reproduced from ROADMAP.md for context only - these are not Phase 1 deliverables and not part of this funding ask:
- Phase 2 - The Decoding Standard (2026 H2) - a SEP draft for a standardized Soroban event schema and registry verification spec;
orbital codegen(CLI that emits TypeScript types, event guards, and hooks from the registry schema); a semantic layer (human-readable event taxonomy + entity labels, published as open data); a hosted registry read API. - Phase 3 - Anchor Events (2027 H1) -
@orbital-stellar/anchor-sdknormalizing SEP-24 and SEP-31 lifecycle events into the standard taxonomy.
Everything previously slated for the old Phase 2–4 wish list - @orbital-stellar/payments, @orbital-stellar/auth, an identity layer, @orbital-stellar/x402, @orbital-stellar/agent-sdk, an intent compiler, a shadow-fork simulator, reactor contracts, @orbital-stellar/analytics, and "10+ SEPs" as a target - is now frozen per ROADMAP.md's Frozen section; none of it is part of this or any near-term funding ask.
Each future phase will be a separate proposal if grant support is sought.
- Funding: $30,000 milestone-released against the six M1–M6 deliverables above.
- Featured-project status on Drips so contributor incentives align with Phase 1 issue throughput.
- Reviewer feedback on the M1–M6 merge criteria - please challenge any milestone whose "done when" condition is not measurable.
Contact, repository links, and license are at the top of this document.
- Orbital repository -
github.com/determined-001/orbital_stellar v0.1.0release notes -CHANGELOG.md- Architecture reference -
docs/ARCHITECTURE.md - Phase 0 completion snapshot -
PROGRESS.md - Multi-year roadmap -
ROADMAP.md - Contributor guide -
CONTRIBUTING.md - Security policy -
SECURITY.md - Stellar Development Foundation - stellar.org
- Horizon API reference - developers.stellar.org/api/horizon
- Stellar RPC reference - developers.stellar.org/api/rpc
- Stellar SDF SCF program - communityfund.stellar.org
- Stellar Wave Program (Drips) - drips.network