Stellar .NET SDK

.NET Stellar SDK that supports API backends with Horizon and Soroban.

   
Category SDKs
Website https://beans-bv.github.io/dotnet-stellar-sdk/
Repository https://github.com/Beans-BV/dotnet-stellar-sdk
First Released April 2018
Intake soft-launch
Budget Requested $15,000

Project Description

The .NET Stellar SDK (stellar-dotnet-sdk) is the official community-maintained SDK for building on Stellar using C# and .NET. Originally ported from the official Java SDK and expanded by Beans BV, it serves .NET developers building backends, APIs, anchors, and Soroban-enabled applications on Stellar.

Current capabilities (v15.0.0):

  • Horizon API: 100% endpoint coverage (50/50 endpoints), including streaming via SSE for 22 endpoints
  • Stellar RPC: 100% method coverage (12/12 methods) for Soroban smart contract interactions
  • Soroban: Full smart contract support — deploy, invoke, extend TTL, event processing, fee-bumped transactions
  • SEPs: 5 Stellar Ecosystem Proposals implemented (SEP-1, 6, 9, 10, 24), enabling anchor discovery, web authentication, KYC fields, and deposit/withdrawal flows
  • Retry policies: Configurable retry with exponential backoff and jitter for both Horizon and Stellar RPC clients via Polly
  • 186 unit test files with property-based testing (FsCheck), mocking (FakeItEasy, Moq), and BDD (SpecFlow)
  • Comprehensive examples for both Horizon and Soroban, including real-world contract invocation patterns

The SDK is published as two NuGet packages (stellar-dotnet-sdk and stellar-dotnet-sdk-xdr) and is used by .NET developers building production Stellar integrations. XDR types are auto-generated from the official Stellar XDR definitions via xdrgen, ensuring protocol fidelity.

Ecosystem relevance:

.NET is the one of the most popular programming language ecosystem globally and the primary backend technology for enterprises in financial services, government, and healthcare. The Stellar .NET SDK enables these developers to integrate with Stellar without maintaining forks or custom implementations.

Team & Experience

Cuong Pham — Software Engineer, primary maintainer

  • GitHub: @cuongph87
  • Discord: cleft931
  • Primary developer responsible for core development, feature implementation, and testing
  • Has extensive experience building on Stellar, with contributions spanning the full protocol surface (Horizon, Soroban RPC, SEPs)
  • Delivered the Json.NET → System.Text.Json migration, all 5 SEP implementations, response model overhaul, and retry mechanism in recent quarters

Jop Middelkamp — Maintainer and reviewer

  • GitHub: @jopmiddelkamp
  • Discord: qbarz
  • Oversees roadmap planning, aligns development with ecosystem needs, and manages the grant relationship with SCF
  • Co-Founder of Beans BV, which has maintained the .NET Stellar SDK since 2024 after taking over stewardship from the original creator (Elucidsoft)
  • Previous SCF participation: Infrastructure Grant (completed), Public Goods Award Q1 2026

The team collaborates with other Stellar ecosystem developers and maintains active communication through GitHub issues and Stellar developer channels. Contributions are reviewed and merged regularly to keep the SDK aligned with the latest network standards.

Retroactive Impact

[TBA]

Past Deliverables

[TBA]

Proposed Impact

Over the next three months, our goal is to transform the .NET Stellar SDK from a backend-only library into a reliable, multi-platform foundation — while keeping .NET backend developers as the primary audience.

1. Protocol 26 readiness — protecting production integrators Protocol 26 “Yardstick” hits Testnet on April 16 and Mainnet on May 6. The SDK must support the new XDR types, result codes, and RPC changes before these dates. Failure to update would break existing .NET integrations and block new ones. This is the most time-sensitive deliverable.

2. Integration tests — shifting from “it compiles” to “it works” The SDK currently has 186 unit test files, but they all run against mocked JSON responses. If Horizon or Stellar RPC change field names, add headers, or subtly change behavior, our tests still pass green while production users break. An integration test suite running against Testnet on every release is the single highest-ROI investment for SDK reliability.

3. Multi-platform preparation — unlocking MAUI, Unity, and Tizen The SDK currently targets .NET 8 only and hasn’t adopted any runtime improvements since .NET 6. This quarter we lay the foundation for multi-platform expansion (the main focus of Q3) by:

  • Multi-targeting to net10.0 + net8.0 + netstandard2.1, which lays the technical foundation for .NET MAUI (iOS/Android), Unity 2022.3+ (games/XR), and Tizen 5.5+ (Samsung smart TVs/wearables) support planned in Q3/Q4
  • Upgrading the codebase to use modern .NET 7–10 APIs where they improve reliability, performance, or multi-platform compatibility — including FrozenDictionary for faster static lookups, Stream.ReadExactly() for safer XDR binary decoding, strict JSON validation with AllowDuplicateProperties, and RespectNullableAnnotations for stronger response model validation
  • Gaining free JIT performance wins from targeting net10.0: stack allocation for small arrays, array interface devirtualization, delegate escape analysis, and improved PGO — all without code changes

This makes the .NET Stellar SDK the most broadly deployable Stellar SDK in the ecosystem and sets up Q3’s full MAUI validation and Wallet SDK development.

4. SEP-45 — closing the most visible feature gap Every peer SDK (Flutter, iOS, Java) has implemented SEP-45 (Stellar Web Authentication with Contract Accounts). We are the only SDK without it. Shipping SEP-45 plus per-SEP compatibility matrices closes this gap and provides field-level coverage transparency for all implemented SEPs.

Proposed Deliverables

Deliverable 1 — Protocol 26 “Yardstick” Support

  • Specific: Update XDR schemas from stellar-xdr v26.0, regenerate C# types via xdrgen, update Stellar RPC response models (getLatestLedger gains ledgerCloseTime, headerXdr, metadataXdr), add new result codes, and update compatibility matrices. Protocol 26 includes: 5 new XDR types (frozen ledger keys — CAP-77), 4 new ConfigSettingID values, 16 new BN254 ContractCostType entries (CAP-80), 4 new result codes, 7 contract spec unbounded array changes, and SCP quorum nesting depth increase.
  • Measurable: SDK builds and passes tests against Protocol 26 Testnet; compatibility matrices updated to reflect v26.0.
  • Achievable: XDR types are auto-generated via xdrgen; manual work is limited to RPC response models and tests. Reference: Flutter SDK Protocol 26 commit.
  • Relevant: Protocol 26 Testnet upgrade is April 16 and Mainnet vote is May 6. Without this update, existing .NET Stellar integrations break.
  • Time-bound: Complete before April 16 (Testnet) and May 6 (Mainnet).

Deliverable 2 — Integration Test Suite

  • Specific: Build an integration test project running against Stellar Testnet with a CI workflow that runs on release tags only. Tests self-provision via Friendbot and are resilient to Testnet resets (next reset: June 17).

    Test infrastructure: Base test class, Testnet configuration, Friendbot helper, CI workflow with secrets management.

    Priority 1 — MUST tests: These validate flows where mocked unit tests are insufficient and real breakage would hurt production users:

    1. Friendbot funding (foundational for all other tests)
    2. Server.RootAsync() (connectivity + protocol version)
    3. SubmitTransaction — sync, async, and fee bump variants
    4. CheckMemoRequired (SEP-29 compliance on real accounts)
    5. AccountsRequestBuilder — fetch account, account data
    6. TransactionsRequestBuilder — query + paginate transactions
    7. PaymentsRequestBuilder — query payments
    8. CreateAccountOperation — create new accounts on-chain
    9. PaymentOperation — native + non-native asset payments
    10. PathPaymentStrictReceive + PathPaymentStrictSend — with real orderbook
    11. ManageSellOffer + ManageBuyOffer — DEX operations
    12. ChangeTrust + SetOptions — trustlines, signers, thresholds, flags
    13. InvokeHostFunctionOperation — Soroban contract invocation
    14. ExtendFootprint + RestoreFootprint — Soroban state management
    15. Soroban RPC full flow — GetHealth → GetAccount → SimulateTransaction → SendTransaction → GetTransaction → GetLatestLedger → GetLedgerEntries → GetEvents
    16. SSE streaming — real Horizon event parsing on at least 1 endpoint
    17. SEP-10 full auth flow — GetChallenge → Validate → Sign → Submit → JWT (against real anchor)

    Priority 2 — SHOULD tests (18h, stretch goal): Additional coverage that expands confidence. Any items not completed in Q2 move to Q3:

    • Remaining Horizon query endpoints: Assets, ClaimableBalances, Effects, Ledgers, Offers, OrderBook, Trades, TradeAggregations, FeeStats, LiquidityPools, PathStrictSend/Receive, Health
    • Remaining operations: AccountMerge, ManageData, BumpSequence, CreatePassiveSellOffer, ClaimableBalance create/claim, Sponsoring (begin/end/revoke), Clawback, SetTrustlineFlags, LiquidityPool deposit/withdraw
    • Remaining RPC methods: GetTransactions, GetLedgers, GetVersionInfo, GetFeeStats
    • SEP-1 (real domain), multi-operation transactions, Federation
  • Measurable: All 17 Priority 1 test areas passing against Testnet (est. 30-40 test methods); CI workflow green-gates releases; Priority 2 coverage as capacity allows.
  • Achievable: The SDK already has Soroban examples demonstrating all patterns; integration test infrastructure builds on the existing NUnit setup. Priority 1 is scoped to the most critical flows. Priority 2 items are independent and can be implemented incrementally.
  • Relevant: Unit tests with mocked responses cannot catch real API behavior changes. Integration tests are the only way to guarantee that SDK releases actually work against the live network.
  • Time-bound: Priority 1 complete by end of the 3-month period. Priority 2 items that don’t fit move to Q3.

Deliverable 3 — Multi-Platform Preparation: Multi-Target + .NET Modernization

This deliverable is the prework for Q3’s full MAUI validation and Wallet SDK development. It has two parts:

Part A — Multi-target NuGet package: net10.0 + net8.0 + netstandard2.1

Retarget both StellarDotnetSdk and StellarDotnetSdk.Xdr to net10.0;net8.0;netstandard2.1. This requires: abstracting the crypto layer (NSec.Cryptography targets net8.0+ only; netstandard2.1 uses Sodium.Core as alternative), adding compiler polyfills for netstandard2.1, adding System.Text.Json NuGet package reference, and conditional compilation for 4 DateOnly usages, 11 ThrowIfNull calls, and 20 ThrowIfNullOrEmpty calls.

Part B — Adopt modern .NET 7–10 APIs

The SDK codebase hasn’t been updated to use runtime improvements available since .NET 7. As part of the multi-target effort, we adopt high-value .NET improvements that enhance reliability, performance, and multi-platform readiness:

  • FrozenDictionary for static lookup tables in JSON converters — ~47% faster reads for immutable data
  • Stream.ReadExactly() in XDR binary decoding — eliminates subtle partial-read bugs that can cause data corruption
  • AllowDuplicateProperties = false — prevents silent data corruption from malformed JSON responses, critical for financial data
  • RespectNullableAnnotations — enforces C# nullability annotations during JSON deserialization, catching malformed API responses early
  • JsonSerializerOptions.MakeReadOnly() — explicit freeze of shared serializer options to prevent accidental modification

  • Free JIT performance gains from net10.0 targeting: stack allocation for small arrays, array interface devirtualization, delegate escape analysis, and profile-guided optimization — all automatic, no code changes required

  • Measurable: Both NuGet packages build and pass all existing unit tests on all three targets; NuGet package validation passes; .NET modernization items verified via unit tests.
  • Achievable: All dependencies except NSec.Cryptography already support netstandard2.0+. The crypto abstraction is the main engineering effort. Dependency compatibility verified via NuGet catalog API.
  • Relevant: Unlocks MAUI (iOS/Android), Unity (2022.3+, Unity 6), and Tizen (5.5+) as target platforms for Q3. net10.0 is the current .NET LTS; net8.0 is the previous LTS (EOL Nov 2026). The modernization items improve correctness and performance for existing backend consumers while preparing the codebase for multi-platform deployment.
  • Time-bound: Complete by end of the 3-month period.

Deliverable 4 — SEP-45 Implementation + SEP Compatibility Matrices

  • Specific: Implement SEP-45 (Stellar Web Authentication with Contract Accounts) and create per-SEP compatibility matrices for all implemented SEPs (1, 6, 9, 10, 24, and the new 45). SEP-45 enables contract-based WebAuth — all three peer SDKs (Flutter, iOS, Java) have already shipped this.
  • Measurable: SEP-45 implemented with unit tests; 6 SEP compatibility matrices published in StellarDotnetSdk/Compatibility/sep/.
  • Achievable: SEP-45 builds on the existing SEP-10 (WebAuth) infrastructure. The SDK already supports Soroban authorization entries needed for contract account authentication.
  • Relevant: Closes the most visible feature gap versus all peer SDKs. SEP compatibility matrices provide field-level coverage transparency matching the format used by Flutter (19 matrices) and iOS (19 matrices) SDKs.
  • Time-bound: Complete by end of the 3-month period.

Deliverable 5 — Release & Verification

  • Specific: Add or adjust tests for new and changed surfaces, update parity matrices, and ship releases.
  • Measurable: Passing test suite (unit + integration), updated matrices, and tagged releases on NuGet.
  • Time-bound: Completed within the 3-month period.

Non-deliverable 1 — Developer Support & Maintenance Responsiveness

  • Specific: Triage and respond to SDK-related GitHub issues, feature requests, and Discord inquiries.
  • Measurable: Issues acknowledged and either resolved, scoped, or explicitly deferred.
  • Achievable: Bounded strictly to SDK maintenance and usage (no general Stellar support).
  • Relevant: Maintains developer trust and reduces adoption friction.
  • Time-bound: Ongoing throughout the 3-month period (~1.5h/week).

Note: If issue volume or support demand is low, unused capacity will be reallocated to Deliverable 2.

Non-deliverable 2 — Small Capacity Buffer

Absorbs unexpected complexity from any deliverable, including unforeseen upstream changes. If unused, reallocated to Deliverable 2 (Priority 2 integration tests).

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

Back to top

This site uses Just the Docs, a documentation theme for Jekyll.