Infrastructure Provider Onboarding

Add an infrastructure provider integration to SDP through the self-service contribution process.

SDP accepts infrastructure provider integrations in the categories below. An onboarded provider is listed as an available integration, not an endorsed or recommended partner. Institutions using SDP are responsible for their own provider due diligence.

Start here

Pick your category, complete its intake form, and review its criteria before you open a pull request.

CategoryIntake formCriteria
Custodial enterprise walletComplete custody intakeDownload custody criteria PDF
RPC infrastructureComplete RPC intakeDownload RPC criteria PDF

A module's own categories publish their intake on that module's pages. If your category has no published intake, contact the SDP team before you open a pull request.

Onboarding steps

  1. Review the criteria PDF for your category.
  2. Complete the matching intake form.
  3. Provide sandbox or playground API access.
  4. Share documentation, test credentials, supported networks, rate limits, and sandbox limitations.
  5. Build the SDP integration, with tests and docs.
  6. Open a pull request that links to the intake submission or tracking issue.

The SDP team reviews intake completeness within five business days. Gate evaluation usually takes one to three weeks, depending on the category, how complete the documentation is, and the technical validation it needs.

Evaluation

Each category uses the criteria linked above. A review starts with hard gates, then a scored evaluation where the category has one. SDP evaluates:

  • Solana compatibility for the category.
  • Stable sandbox or playground access.
  • Clear API and integration documentation.
  • Predictable error handling and testability.
  • Operational readiness and support.
  • The regulatory, compliance, or security posture the category requires.

A provider that doesn't clear the required gates may be tracked for future support, but isn't presented as available until the gaps close. A provider that clears evaluation must still be configured by the deployment. It's then either generally available to every organization, or needs a per-organization Manual Provider Activation while commercial or operational onboarding finishes.

Access requirements

Provide access that supports repeatable validation:

  • Sandbox API keys or equivalent credentials.
  • Test accounts, wallets, endpoints, or settlement rails, when the category needs them.
  • The Solana networks you support.
  • Known rate limits, feature flags, and sandbox limitations.
  • A technical support contact for the review.

Pull request expectations

An SDP infrastructure provider contribution usually includes:

  • Provider metadata and capability registration.
  • API support for setup, configuration, and the category's runtime operations.
  • Dashboard support, where it applies.
  • Tests for setup, success paths, failure states, disabled configuration, and missing credentials.
  • User-facing docs for setup, sandbox behavior, and provider limits.

Open the pull request once intake is complete, or once the SDP team has opened a tracking issue while intake is finalized.