Six Vendors, One API: Inside the Solana Developer Platform
The Solana Foundation has open-sourced Solana Developer Platform (SDP) — an enterprise toolkit that bundles wallets, token issuance, custody, fee sponsorship, and compliance checks behind a single API. The hosted version lives at platform.solana.com and the repository is now public at github.com/solana-foundation/solana-developer-platform.
For teams shipping regulated products on Solana — stablecoin issuers, fintechs preparing for Australia's payments system overhaul, marketplaces doing programmable payouts — this is the first reference architecture the Foundation itself has published.
This note covers what SDP consolidates, how it is built, who should care, and the realities that still need diligence before you ship on it.
What SDP Actually Is
If you have tried to launch a Solana product with real users, you have probably built — or budgeted to build — most of this list:
- Custody: a signer that holds private keys without becoming your worst incident
- Fee sponsorship: a paymaster so users are not asked to top up SOL just to use your app
- RPC: at least one paid provider, ideally with failover
- Token rules: transfer restrictions, allowlists, metadata, fees — typically via Token-2022 extensions
- Compliance: sanctions screening and AML against every wallet you touch
- Fiat ramps: at least one provider for AUD or USD on- and off-ramps
- Auth and multi-tenant orgs: dashboards, API keys, team access controls
- An operational dashboard: so your team can see what is happening in production
SDP collapses all eight into one API surface. You receive one key, and the platform routes to the appropriate provider underneath.
Concretely, the public surface today covers seven API families: health, api-keys, wallets, projects, issuance, payments, and compliance. That is 71 endpoints at the time of writing, generated from a single OpenAPI source of truth.
Provider Coverage
The platform integrates the relevant commercial providers in each category rather than reimplementing them.
Custody and signing. Local signer, Dfns, Turnkey, Coinbase CDP, Privy, Para, Fireblocks.
Fee sponsorship. Kora paymaster or native gas.
RPC. Helius, Triton, Alchemy, QuickNode — proxied with round-robin failover.
Token issuance. Mosaic SDK on top of Token-2022 extensions.
Compliance and sanctions. TRM, Elliptic, Range, Chainalysis.
Fiat on and off ramps. MoonPay, Lightspark Grid, BVNK.
Auth and multi-tenant orgs. Clerk.
The repository introduces a concept called Provider Availability: whether an organisation can use a given provider in the current deployment environment. The Foundation explicitly distinguishes this from runtime health, project-level selection, and entitlement — a careful piece of domain modelling that signals this codebase was written with multi-tenant, regulated operators in mind.
Architecture
SDP is a Turborepo monorepo with three apps and a shared types package.
apps/sdp-api is the API service. Hono on Cloudflare Workers, with Postgres (via Hyperdrive in production) and KV bindings for API keys, rate limits, sessions, and cache. The OpenAPI spec is hand-written and used to generate both client documentation and the AI discovery files (llms.txt, llms-full.txt).
apps/sdp-web is the operator dashboard. Next.js and Clerk for auth, with Sentry instrumentation, Playwright end-to-end coverage, and a hosted API playground.
apps/sdp-docs is the public docs site. Fumadocs on Next.js, with API reference and Postman collection both regenerated from the OpenAPI source.
packages/sdp-types holds shared runtime types and site constants.
Infrastructure helpers live in infra/postgres (local docker-compose) and infra/kora (paymaster, with a Cloud Run deployment script). Secrets in development go through Doppler; production uses Cloudflare's secret management.
This is a serious codebase. Tests run with Vitest under the Cloudflare Workers pool. Generated artefacts are clearly demarcated and not hand-edited. Public and internal API surfaces are separated — rpc, admin, onboarding, auth, organizations, and members are deliberately kept out of the public AI discovery files. That separation alone tells you who the maintainers are writing for.
Why This Matters for Australian Fintechs
Two simultaneous pressures make SDP particularly relevant to Australian teams.
First, the payments system overhaul is reshaping how value moves between institutions, and a credible AUD stablecoin landscape is forming on top of it. Several teams are already exploring Solana as the settlement layer. The technical work — issuance, transfer rules, compliance — is the same regardless of jurisdiction, but the regulatory posture is not. SDP's compliance providers (TRM, Elliptic, Range, Chainalysis) are the same providers Australian institutions already engage for fiat AML; routing those through a unified Solana stack reduces integration risk.
Second, the self-hosted mode. SDP supports SDP_DEPLOYMENT_MODE=self_hosted, which removes the dependency on the Foundation's hosted Clerk-synced entitlement model. In this mode every configured provider is automatically available; per-organisation overrides remain as a disable-only mechanism. For teams under AFSL or APRA scope, the ability to run the entire stack on your own infrastructure — your keys, your Postgres, your RPC — is non-negotiable, and SDP supports it as a first-class deployment target.
The minimum self-hosted configuration is genuinely minimal: a local signer keypair, a custody encryption key, a fee-payer keypair, and a single RPC endpoint. Generated locally with pnpm --filter @sdp/api keygen:local, the whole stack comes up in well under an hour.
Realities to Diligence Before You Build on It
SDP is well-engineered, but it is also early. Before any team commits architecture decisions to it, weigh the following.
Pre-mainnet, unaudited. The README is explicit: this codebase has not been audited and is not intended to custody production funds or run mainnet financial workflows without your own security review. Devnet integrations are the primary supported path today.
Clerk dependency in managed mode. The hosted product synchronises organisations and tier entitlements through Clerk webhooks. If you want to operate independently of that model, self-hosted mode is the path — but you take on full responsibility for tenant isolation, role-based access, and webhook reconciliation.
Token-2022 extension surface. SDP's issuance flow leans on Mosaic and Token-2022 extensions. These are powerful — transfer hooks, permanent delegate, allowlist transfer fees, confidential transfers — but each extension has its own ecosystem support profile. Before issuing a regulated token, confirm that the wallets, exchanges, and custodians your users rely on actually support the extension combination you select.
Fee payment provider choice. The repository explicitly warns against defaulting to the Kora paymaster URL the Foundation ships, because it points at a public devnet endpoint. For production self-hosted deployments, either run your own Kora instance or use native gas with a funded fee-payer keypair.
Provider runtime health is not provider availability. SDP models "is this provider configured and entitled" as a separate concept from "is this provider currently up." Operational dashboards and alerting for the latter are the operator's responsibility.
How to Evaluate It
The fastest way to form a view is to run it locally.
git clone https://github.com/solana-foundation/solana-developer-platform.git
cd solana-developer-platform
pnpm install
cp apps/sdp-api/.dev.vars.example apps/sdp-api/.dev.vars
pnpm db:postgres:up
pnpm --filter @sdp/api db:postgres:bootstrap
pnpm dev
The API exposes its OpenAPI playground at http://localhost:8787/docs. The dashboard runs at http://localhost:3000. Self-hosted mode (SDP_DEPLOYMENT_MODE=self_hosted) removes the dependency on Clerk for the API path; the dashboard still requires Clerk credentials to render the auth-gated routes.
We ran the stack end-to-end on devnet in roughly ten minutes after provisioning Docker and Doppler. The API responded 200 on /health, OpenAPI generation succeeded, and wrangler dev reported all expected bindings — KV namespaces, Hyperdrive, environment variables — wired correctly. The documentation site rendered without manual intervention.
Bottom Line
If you are issuing a stablecoin, building enterprise payouts on Solana rails, or weighing whether to integrate six vendors yourself, SDP is now the reference architecture worth measuring your design against — even if you choose not to adopt it directly.
For Australian teams in particular, the combination of a credible compliance-aware provider set, a viable self-hosted deployment model, and an open-source licence is meaningful. It does not replace your security review, your legal review, or your own infrastructure decisions. It does replace the months of vendor selection, contract negotiation, and glue code that have historically gated production-grade Solana products.
We will continue tracking SDP's path to mainnet and audit, including how the Token-2022 extension surface evolves and whether the Foundation publishes a self-hosted production reference. The repository is explicit that "full self-hosting is a work in progress."
Resources
- Repository: github.com/solana-foundation/solana-developer-platform
- Hosted platform: platform.solana.com
- Public documentation: platform.solana.com/docs
About Milysec
Milysec is an Australian venture studio building at the intersection of cybersecurity and blockchain. We create products and services on Solana that make the decentralised web safer, faster, and more accessible.
Learn more about Milysec →