The developer economy for Solana.

The next generation of onchain applications will be built by developers, creators and communities who can turn ideas into working software without starting from zero.

Yet the infrastructure surrounding token launches has largely focused on asset creation rather than the software those assets could represent.

SDK takes a different approach.

We are building an ecosystem where anyone can create functional SDKs, test them, publish them to a shared marketplace, integrate them into applications and launch tokens associated with working software.

Developers can build reusable tools. Other users can discover, customise and deploy them. Communities can form around software with demonstrable utility.

At the centre is $SDK, the native ecosystem token connecting launches, marketplace activity and holder rewards.

Make creating, distributing and monetising software on Solana accessible to everyone.

SDK connects software creation, publication, reuse, execution and optional token launches. A developer does not need to launch a token in order to publish or use software.

• AI SDK Builder

  A conversational development environment that turns natural-language instructions into structured, executable SDKs.

• SDK Library

  A public marketplace of working, reusable SDKs. Developers can submit creations for review and publication.

• SDK Remixing

  Users can customise an existing SDK instead of rebuilding common functionality.

• Execution infrastructure

  A shared execution engine, authenticated API access, and a universal SDK client.

• Token launches

  Creators can launch a token associated with working software. Production launches use native $SDK as the quote asset.

• The SDK ecosystem

  One environment for developers, software publishers, token creators, and native holders.

SDK is building a marketplace where developers publish working software, other people discover and reuse it, and the original developer can earn from a qualifying third-party token launch.

1. 01

   Create

   Build an SDK in the AI Builder, or remix an existing implementation.

2. 02

   Test

   Run the SDK and confirm it returns a usable result.

3. 03

   Submit

   Send completed software for Library review.

4. 04

   Publish

   Approved SDKs become discoverable in the Library.

5. 05

   Distribute

   Others can find the SDK, call it, and use it in a supported launch.

6. 06

   Earn

   The original developer can receive creator-fee revenue from a qualifying third-party launch.

Publishing software is independent of launching a token. An SDK can live in the Library with no associated token. The commercial opportunity is for developers who contribute software other people choose to reuse.

Three activities connect the economy: software creation and distribution, token-launch activity, and creator-fee sharing.

SDK supports reusable software and token launches. The allocation of applicable creator fees depends on the launch category. The percentages below are shares of those child-token creator fees. They are not shares of total trading volume.

When a developer launches a token for their own SDK, the 85% launcher share is received by that developer in their role as launcher.

A developer can publish an SDK and receive 25% of applicable creator fees when a separate launcher uses it in a qualifying community-SDK token launch.

The protocol share is retained as part of the operating model. It is not a promise that all protocol income is distributed to native $SDK holders. Child-token creator fees are also separate from native $SDK holder rewards.

Ecosystem pairing

Production child-token launches pair with native $SDK, rather than SOL or USDC.

Holder participation

Eligible holders participate in native creator-fee SOL allocations under the applicable protocol reward rules. An allocation is an entitlement. It is not, by itself, a completed payment.

Shared ecosystem infrastructure

$SDK connects the launch infrastructure and its token economy.

Onchain transparency

Verified launch activity and native reward accounting are represented through supported onchain evidence and platform records.

Holding $SDK is not required to create, test or submit software.

After applicable collection and reserve treatment, confirmed native creator-fee SOL is allocated between eligible holders and the protocol.

50%

Native holder allocation

50,000 $SDK

Minimum eligible holdings

5 minutes

UTC accounting windows

SOL

Claimable reward asset

Holder eligibility

A wallet must hold at least 50,000 whole native $SDK tokens at the relevant eligibility snapshot. Reward allocations are proportional to qualifying holdings under the protocol rules.

Reward windows

Native accounting operates in 5-minute UTC windows. Windows track qualifying creator-fee collections, reserve treatment and eligible allocations. A completed accounting window does not guarantee an allocation or a payment.

Claimable SOL

Holder rewards are recorded as claimable SOL entitlements. Allocated, claimable and successfully claimed rewards are distinct statuses. A reward is not paid until the relevant onchain claim is confirmed.

Unassigned allocations

Where eligible revenue exists but there are no qualifying holders, the holder portion is recorded as unassigned rather than silently retained by the protocol.

No automatic buybacks

The native 50/50 model does not depend on automatic buybacks, new token issuance or token airdrops. Rewards are derived from eligible SOL creator-fee revenue.

Supply and distribution

Full native token supply, distribution and launch parameters will be published following finalisation of the official token configuration.

Creators begin with functioning SDK software, either built through the AI Builder or selected from the Library. A supported token launch associates a token with that software.

Production child-token launches use native $SDK as the quote token. Verified launches become discoverable through Paired and individual token pages.

The software remains the product.

A token launch does not replace the SDK. The software can continue to be discovered, tested, remixed and integrated through supported interfaces. Token creation remains optional.

Published SDKs run through a shared execution engine. Applications call them with authenticated API requests. The universal SDK client provides one interface for those calls, with a consistent request and result shape.

The client is distributed from this repository. It is not a package on the public NPM registry.

API execution and blockchain signing are separate. An account-wide API key authorises permitted execution of published SDKs. It does not independently authorise wallet signing, a token launch, publication, or a transfer of funds.

Developers contribute useful SDKs. The marketplace attracts creators. Creators use the software and can launch a token with it. Qualifying activity can generate creator-fee opportunities, including a share for the developer who published a community SDK. Native $SDK connects the supported launch ecosystem. A larger catalogue gives the next participant more to build on.

This is the intended economic model. It is not a guarantee of future activity, fees or returns.

A growing developer marketplace

Expand the breadth and quality of published SDKs.

Accessible software creation

Make the journey from an idea to a functioning SDK progressively simpler.

Connected economic infrastructure

Connect software publication, integration, token launches, creator-fee sharing and native token participation.

The objective is not simply to increase the number of launches. It is to increase the amount of useful software created, distributed and adopted.

• SDK depends on Solana and on external infrastructure. Either can be unavailable, delayed or changed.
• Smart-contract behaviour and operational processes can fail, and a failure can affect execution, a launch or reward accounting.
• Token prices and liquidity can move sharply. A token can lose some or all of its value.
• Creator fees vary with activity. They are not guaranteed.
• Native holder allocations are not guaranteed payouts. A window can complete with nothing to allocate, and a recorded entitlement is not a confirmed payment.
• Library publication depends on review. API execution is subject to account limits.
• Published platform terms can change.

A native holder allocation is not ownership of SDK's operating business, and it is not an entitlement to all of the company's revenue.

SDK brings development, discovery, reuse, distribution and tokenisation together within one ecosystem.

A developer can publish a tool without launching a token. A creator can build on existing software without starting from zero. A community can discover an application and its associated token.

$SDK connects the native launch infrastructure and the defined fee-allocation model.

Build software. Launch on Solana.