Solana Tokens: How I Would Deploy a $100K Product Budget

If I had $100,000 to launch a Solana product or protocol, I would not start by choosing a token ticker. I would start with a harder question: what exactly should the user own, and where should that ownership live?

That decision determines the accounts we need to create, the indexer a product depends on, the wallets and marketplaces it can reach, and the security work that must happen before launch. It is an architectural decision disguised as a token decision.

Solana’s advantage is its modular ownership stack. Builders can choose between balance-based SPL tokens, mint-backed NFT metadata, single-account Core assets, and compressed NFTs created through Bubblegum. Those choices are not interchangeable: they define what users own, how the state is stored, how the product is indexed, and which wallets and marketplaces can support it.

The useful question for a founder is not which standard is the most fashionable. It is which standard makes the product’s promised ownership legible, transferable, measurable, and affordable to operate.

First, define the thing being owned

Solana’s original token documentation separates a token mint from the token accounts that hold balances. A mint carries properties such as supply, decimals, and authorities. A token account records a balance for an owner. That distinction matters: a holder can control a balance while an issuer may still retain mint or freeze authority.

At the implementation level, the pinned createMint function, lines 21–46 creates and initializes the mint. The Mint state interface, lines 19–37 exposes the mint authority, supply, decimals, freeze authority, and extension data. Its getMint implementation, lines 65–116 also checks that the account is owned by the expected token program before decoding it.

[Click to expand]

That is the first ownership model: a fungible balance held in a token account. It is the right starting point for rewards, credits, payments, stable-value units, voting weight, and other products where the user owns an amount rather than a unique object.

The four models I would put in front of a founder

1. SPL Token and Token-2022 for balances

Token-2022 is a separate Solana token program with extensions. The program’s own constants identify the original SPL Token program and Token-2022 by different program addresses. The official extension guide describes features such as transfer fees, transfer hooks, confidential transfers, and required metadata.

I would choose Token-2022 when the product needs those rules to travel with the token. A transfer fee, a restricted transfer path, or required metadata should not live only in a frontend promise. It should be part of the token’s execution model when that is the intended product behavior.

The cost is integration work. A wallet, exchange, marketplace, or internal service has to understand the extensions we select. The Token-2022 source, for example, carries transfer-fee configuration and fee calculation as extension state in the transfer-fee implementation. For a $100K launch, I would choose the smallest extension set that expresses the product and test every transfer path against it.

[Click to expand]

I would not use a fungible token as a substitute for product design. If the real product is a membership, a game item, or a claim on a unique object, forcing that object into a balance-based model usually creates confusing metadata and redemption logic.

2. Token Metadata when compatibility is the constraint

Metaplex Token Metadata adds metadata to fungible and non-fungible tokens through accounts derived from the mint. The implementation makes the relationship concrete: the createNft helper, lines 8–25 builds the creation and mint flow, sets the token standard to non-fungible, and mints one unit. The metadata account definition, lines 60–143 stores fields such as the mint, URI, creators, mutability, collection, and token standard.

[Click to expand]

I would choose Token Metadata when existing wallet, marketplace, and tooling compatibility is more valuable than a simpler account layout. It remains a recognizable path for a product that needs a mint-backed NFT and broad support across older Solana integrations.

The tradeoff is architectural weight. The ownership object is spread across a mint, token account, and metadata-related state rather than represented by one Core asset account. That is not automatically a problem. It becomes a problem when the team assumes ‘NFT’ is one account and then discovers that every indexer, transfer flow, and update authority has a different responsibility.

3. Metaplex Core for a standard NFT product

Metaplex Core uses a single-account design for a standard NFT asset and adds behavior through plugins. The Core create helper resolves the initial owner and update authority before creating the asset. The generated AssetV1 account exposes fields for the owner, update authority, name, URI, and sequence. The transfer instruction treats the current owner and recipient as explicit accounts.

For a new NFT-based product, Core is my default starting point when the asset needs direct ownership semantics, plugins, and a clean account model. That is a judgment about a new build, not a claim that every existing collection should migrate. The product still needs a compatibility check against the wallets, marketplaces, and indexers that its users will actually use.

[Click to expand]

Core also makes the counting problem easier than compressed NFTs. A Core collection exposes numMinted and currentSize, with the collection documentation defining the first as the total ever minted and the second as the number currently in the collection. Those are useful collection-level measures, but they are not the same as unique owners or active users.

4. Bubblegum v2 for very large asset sets

Bubblegum is the Metaplex program for compressed NFTs. A compressed NFT is represented as a hashed leaf in a Merkle tree, while the detailed state is recorded in transaction history and made convenient to query through a DAS-enabled indexer. The Bubblegum v2 documentation recommends v2 for new work and states that v2 trees are not backward-compatible with v1 trees.

The implementation makes that concrete. The mintV2 helper, lines 19–40 passes the leaf owner, delegate, metadata, and collection inputs. The leaf schema source, lines 25–139 distinguishes v1 and v2 and shows the additional v2 fields. The mint processor, lines 46–162 enforces the matching tree version.

[Click to expand]

This is attractive when the product needs to issue a very large number of assets. It also moves part of the product into infrastructure: the DAS API is the practical query layer for Core, Token Metadata, and compressed assets, and the asset-by-owner method is the kind of method a wallet or account page needs.

I would choose Bubblegum v2 for a large distribution, loyalty, ticketing, or game-inventory system only after testing the target wallet and marketplace paths. Metaplex’s current v2 compatibility page labels adoption as in progress. The lower storage cost is real, but it does not remove the need to pay for indexing, proofs, support, and an escape path when a user needs interoperability with a regular account-based NFT.

The launch decision I would trust

With a $100K launch budget, I would spend the next week defining the user’s ownership, the authorities that control it, and the infrastructure the first cohort will rely on. An ecosystem-wide token census belongs in a research appendix. It does not decide a first launch.

I want one sentence that the whole company can repeat: what does a user own after the transaction clears? That sentence determines the model, the support burden, and the product flows we need to test.

Product promise	Start with	Sign off before the pilot
Users hold a spendable balance, credit, or voting unit	The original SPL Token program, or Token-2022 when a named extension is required	Mint and freeze authority, the smallest extension set, target-wallet support, and a recovery path
Users hold a unique asset that depends on existing NFT infrastructure	Token Metadata	Update authority, mutable metadata policy, and target wallet and marketplace behavior
Users hold a new NFT asset with direct ownership and plugins	Metaplex Core	Plugin authority, transfer behavior, and support across the launch audience’s wallets and indexers
Users receive a large inventory of claims, tickets, or game items	Bubblegum v2	DAS provider, tree authority, proof and indexing support, and an interoperability plan

The model becomes the launch brief. I would write the ownership promise, authority map, compatibility matrix, and support runbook before allocating the product build. A founder or CEO can make a useful go or no-go call from that page.

[Click to expand]

The Blockworks charts I use for launch context

The ownership model tells me what the product must ship. Blockworks’ Solana overview helps me judge the network and application activity around the launch. I use those charts to set pilot scope and operating assumptions.

I check the overview group for the network activity and application revenue surrounding the product.

For a liquid fungible or stable-value unit, I use the Solana tokens dashboard to assess market context. I choose the ownership model from the product promise and operating constraints.

The research question comes later

An ecosystem-wide count can be useful for market research or diligence. It needs separate definitions for fungible mints, standard assets, and compressed leaves, plus a fixed provider and time window. I would commission that work only when it changes diligence or an integration decision.

How I would allocate the $100K

This is my starting budget for a narrow product launch, not a market benchmark and not a recommendation to buy any asset.

Workstream	Budget	Reason
Protocol design, threat model, and independent review	$25,000	Decide authorities, transfers, recovery, upgradeability, and failure modes before users bring money or reputation to the product
Product, wallet, and transaction UX	$30,000	Make ownership understandable in the flows users actually touch, including signing, transfer, redemption, and recovery
Indexing, analytics, and explorer-grade observability	$15,000	Build the counts, activity views, and support tooling that the standard does not provide by itself
Testnet, mainnet simulation, and pilot operations	$15,000	Test every authority and transfer path with real wallet and RPC combinations
Distribution and integration work	$10,000	Work with the first customers, wallets, marketplaces, or protocol partners instead of assuming compatibility
Reserve	$5,000	Hold cash for an unexpected integration, RPC, or security issue

If the product moves user funds through a permissionless protocol, I would increase the security line and reduce the initial scope. I would treat $100K as an MVP and pilot budget, not as proof that a production-grade financial protocol, full audit program, liquidity plan, and go-to-market campaign can all fit comfortably inside one envelope.

My current decision rule

For a fungible reward, payment, voting, or credit unit, I would begin with the original token program or Token-2022 and write down every extension before writing the frontend.

For a new, standard NFT product, I would begin with Core and verify its wallet and marketplace support against the actual launch audience.

For a huge inventory or distribution event, I would test Bubblegum v2, budget for DAS from the first sprint, and design the decompression or interoperability path before minting the first leaf.

For a product that depends on existing NFT infrastructure more than it depends on a clean account model, I would still consider Token Metadata.

The founder’s mistake is to ask, ‘Which Solana standard is best?’ The better question is, ‘Which ownership object can my $100K product explain, secure, index, and support?’ Once I can answer that, the standard is usually much less mysterious.