Know what’s
inside your coin.

#What Stocked does

Stocked creates a Solana coin with a treasury holding two selected tokenized stock assets. The coin trades through Pump.fun’s markets. Its treasury provides a separate redemption mechanism: burn an eligible quantity of the coin and receive a proportional quantity of both reserve assets.

Three things exist independently: the coin you can trade, the two stock tokens in its reserves, and the market where the coin trades. A trade changes who holds coins. A redemption destroys coins and removes their share of the reserves. Fee reinvestment, when configured for that coin, buys more stock tokens for the reserves without issuing more coins.

1. 01Select two assets

   Choose distinct supported stock mints and a SOL budget for each.

2. 02Launch and fund

   Buy both stocks, create the coin, and activate its backing together.

3. 03Trade or redeem

   Sell the coin in its market, or burn it for a share of both stocks.

A stock-backed coin is not automatically worth the same amount as its backing. Market prices may include a premium or discount. The reserve may contain only a small fraction of a stock token, and one coin may represent a very small fraction of that reserve.

#Choose your path

If you already started a launch, continue its saved record before creating another one. If your coins are locked elsewhere, read locks and external burns first. If a transaction’s outcome is unknown, read recovery before approving a replacement.

You can read this documentation and inspect public accounts without connecting a wallet. Connecting enables wallet-specific balance checks and signing. Reading a public account neither transfers its assets nor authorizes a future transaction.

#Supported stock assets

The application includes the full issuer catalogue of Solana xStocks. Browse and search every asset in the homepage catalogue; commonly selected mints are shown below. A basket must contain two different assets. Availability also depends on the on-chain supported-asset registry, usable Jupiter routes, liquidity, and the stock issuer’s current transfer controls. A listed ticker alone does not guarantee a launch can execute.

Always identify a token by its full mint address. Names, symbols, images, and social links can be copied. A coin named after a company is not proof that it contains that company’s tokenized stock; inspect its verified reserves.

xStocks are issuer-defined financial instruments providing exposure to referenced equities or ETFs. They do not grant the same rights as directly holding company shares, including shareholder voting rights. Eligibility, issuer redemption, and jurisdictional restrictions are governed by their terms. See the issuer’s product legal overview ↗ and xStocks risk disclosure ↗.

Stocked redemption delivers the on-chain stock tokens. Exchanging those tokens for cash, brokerage shares, or another cryptocurrency is a separate process outside this treasury instruction.

#Wallets and permissions

Use a compatible Solana wallet with mainnet SOL. SOL pays for the stock purchases, any dev buy, and applicable transaction and account costs. Stock balances you already hold are not automatically substituted for the SOL purchase budgets of a new atomic launch.

The current atomic launch path uses one creator transaction approval and does not require the legacy save-progress message. Your wallet may still present its own connection or security prompts. A series of message signatures is not evidence that stock purchases or coin creation have happened; an on-chain transaction signature and confirmed account changes are the evidence.

The app does not request your wallet seed phrase or wallet private key. It creates a separate temporary coin-mint signing key during launch and protects that key locally in browser storage. That key is not your wallet key. Losing browser storage before completion can remove information needed to resume the prepared coin.

Use the same wallet and website origin when resuming. Browser storage is isolated by domain, browser profile, and device. Disconnecting or changing wallets clears the redemption review; review again before signing.

#Create a coin

Step 1 · Choose the basket

Select two different supported stocks. The basket preview carries those selections into the remaining steps. The order of asset A and asset B identifies their budgets and reserves; equal budgets are not required. Both sides need a positive purchase amount.

Step 2 · Set details and budgets

Provide the coin name, ticker, description, and image. PNG, JPG, GIF, and WEBP images are accepted up to 5,000,000 bytes; the actual file signature must match its declared format. A renamed text file will not pass image validation. Metadata is prepared before the financial transaction.

Add optional Website, X, and Telegram links. Valid HTTP or HTTPS addresses are supported; recognizable bare domains are normalized to HTTPS. Links may not contain embedded usernames or passwords. Each link is limited to 2,048 characters. These are public metadata: do not put access tokens, private invitation secrets, or personal recovery information in them.

Enter a SOL budget for each stock and a separate dev-buy maximum. A zero dev buy means no initial coin purchase. The stock budgets buy backing for the full coin supply; they are not credited toward your personal coin allocation. Select stock slippage as a percentage and review what that means before continuing.

Step 3 · Review and approve

Review the exact stock pair, coin identity, budgets, route minimums, and wallet costs. The service prepares the transaction, checks the necessary accounts, and simulates the result. Approve the financial transaction in your wallet only when those details match your intent.

After approval, the application saves the signed transaction before broadcasting it. Wait for confirmation. A completed launch should have a real coin mint, both funded reserve accounts, an activated treasury, and a transaction link. The success page links to the coin’s market and treasury information.

#What one transaction includes

For a new atomic launch, the financial actions are combined into one Solana transaction: buy stock A through Jupiter, buy stock B, create the Pump.fun coin, perform the optional dev buy, initialize the treasury, and activate it. When creator-fee reinvestment is enabled for that launch, its policy is initialized in the same transaction.

All stocks received from the two purchases go directly to the canonical treasury reserves. Minimum outputs are protections against receiving too little; the current atomic path does not return better-than-minimum stock output to the creator’s wallet.

If an instruction in that transaction fails, its state changes roll back together. Network fees can still be charged. This transaction-level guarantee does not reverse earlier independent transactions or off-chain preparation. See Solana’s transaction model ↗.

Platform preparation happens separately

The platform’s operating wallet first prepares two reserve token accounts and an address lookup table so the combined transaction fits Solana’s account and message limits. These are separate sponsor transactions and do not require the creator to approve each one. Preparation can take longer than the final wallet interaction.

The lookup table is frozen after verification. Its rent is not later reclaimable by an administrator. Sponsored setup is therefore a real platform expense even when a user abandons a launch.

Older launches follow their saved process

Legacy launches may have separate reservation, stock-purchase, creation, and funding transactions. An interrupted legacy launch can leave already purchased stocks in the wallet. Its later failure does not reverse earlier confirmed purchases. Do not assume the new atomic rollback guarantee applies retroactively to those records.

#Budgets and costs

Keep the asset purchase budget, the coin purchase budget, and operating costs separate. The amount of SOL sent to buy stocks is not the number of stock tokens received, and the dev-buy maximum is not a guaranteed quantity of coins.

For example, stock budgets of 0.5 SOL and 0.5 SOL with a 0.2 SOL dev-buy maximum create a purchase budget of 1.2 SOL before additional charges. Only the first 1 SOL is intended to purchase stock backing. The 0.2 SOL buys coins; it does not become another 0.2 SOL of stock reserves.

Account rent, applicable Pump or trading fees, and network fees depend on the accounts and instructions in the actual launch. The wallet’s transaction review is the final place to examine those charges. A failed simulation does not authorize a debit, but a failed transaction submitted on-chain can still consume its network fee.

The service’s preliminary wallet-funding check adds 0.005 SOL to the purchase budgets. This is a screening buffer, not a promise that 0.005 SOL covers every possible account and network charge. Passing it does not replace simulation or the final transaction-cost review.

No daily launch allowance

The current service has no daily setup quota and no launch-wallet allowlist. It still needs enough real SOL in the sponsor wallet to fund preparation. It reserves up to 0.03 SOL per new preparation and retains a 0.01 SOL buffer for shared operations. Outstanding preparations count against available funding until their outcomes are reconciled.

A recognized saved preparation reuses its funding reservation. Starting over unnecessarily can cause another setup expense. “Setup funding unavailable” means the service needs operating funds or unresolved reservations need checking; it is not a rule that only certain wallet owners may launch. Standard request throttling and transaction validation still apply.

#Quotes and slippage

A quote estimates the stock output available for a specific SOL input and route at a specific moment. It expires because prices, pool balances, and transaction blockhashes change. An old quote is not a promise that a later purchase can receive the same quantity.

The launch form uses percentages: enter 1 for 1%. Its accepted range is 0.01–3%. Internally, that becomes 1–300 basis points; 100 basis points means one percent. If a quote expects 10 stock tokens at 1% slippage, a simplified minimum is 9.9 tokens. The actual reviewed minimum is calculated in whole token base units and encoded in the transaction. Jupiter’s quote documentation ↗ explains expected output and minimum thresholds.

Price impact and slippage are different. Price impact is the effect of the proposed trade on available liquidity. Slippage is the tolerance between the quoted and executable result. Increasing slippage does not create liquidity and can make a worse execution acceptable.

The coin dev buy uses a separate, currently fixed 10% token-output slippage tolerance in the builder, with a SOL spending cap. Editing stock slippage does not change that coin-buy tolerance. Read both the stock minimums and the coin purchase in the wallet review.

When a fresh route falls below a reviewed minimum, the launch should stop rather than silently reduce your protection. Refresh or rebuild an unsigned launch with a new review. If an attempt is already signed, resolve that exact attempt before replacing it.

The quote display has a 30-second validity window. The current builder uses supported direct, exact-input routes rather than arbitrary split or intermediate routes. It also checks a maximum serialized launch size of 1,232 bytes and at most 64 accounts. These constraints can reject a route that would work as a standalone stock swap.

#The coin-to-stock ratio

At treasury initialization, the program records the coin mint’s entire existing supply as its redeemable supply. It does not use only the creator’s holdings, the dev-buy quantity, the number of unlocked wallet coins, or a market website’s circulating-supply estimate.

The contract calculates this in integer base units, rounding each stock output down. Both stock outputs must be nonzero. On a successful redemption it burns the coins, transfers both outputs, and decreases the stored redeemable supply by the amount burned.

Coins held by the Pump bonding curve, trading pools, a lock contract, other wallets, and the creator are all part of the recorded supply. Moving or locking coins does not destroy them. Custody and lock restrictions do not increase another holder’s proportional share. The authority’s separate withdrawal instruction is not limited by its coin holdings.

What changes the ratio?

Adding stock tokens without adding coin supply increases the stock backing per remaining coin. Creator-fee reinvestment does this when its purchases execute successfully. A normal proportional redemption removes both coins and their corresponding assets, so the ratio for remaining holders is broadly preserved, apart from integer rounding. An authority withdrawal reduces reserves without reducing supply, so backing per coin may fall to zero.

Simply displaying fewer digits or changing a coin’s denomination does not increase anyone’s economic share. Excluding still-existing locked or market-held coins from the denominator would reassign their claims; it is not an arithmetic correction. The present contract has no arbitrary ratio-setting instruction.

Burns made outside Stocked are a separate current limitation: the mint supply decreases, but the treasury’s stored supply does not automatically synchronize. Read external burns before using a wallet’s generic burn function.

#Redeem your coins

Redemption exchanges an irreversible burn for stock tokens already held in the treasury. It does not sell your coin through a market, does not use its trading price, and does not convert the stocks to SOL or dollars.

1. Select the verified treasury. Confirm its coin mint and the two underlying stock mints. The same ticker may belong to unrelated coins.
2. Connect the wallet holding unlocked coins. Locked coins, coins in a pool, and coins owned by a different wallet cannot be spent merely because you are the project creator.
3. Enter the quantity to burn. Enter coins in their normal denomination, not raw base units. The form converts the amount using the coin mint’s actual decimals.
4. Review fresh reserves. The current review refreshes the treasury and available wallet balance. It displays the coin quantity, your percentage of the recorded supply, and the minimum amounts of both stocks.
5. Approve the wallet transaction. The transaction is simulated and checked again before signing. The program enforces the stock minimums on-chain.
6. Inspect the receipt. Confirm the burned amount, actual stock amounts received, transaction signature, and network fee. The actual outputs may exceed the reviewed minimums if backing increased.

One usable, unfrozen token account must contain enough coins for the requested burn. If a wallet’s coins are split across multiple token accounts, the current transaction builder does not consolidate those accounts automatically. Choose a smaller amount or combine eligible balances using your wallet’s own controls.

The recipient must have suitable stock token accounts; the transaction may create them, which requires SOL for account rent. Keep some SOL in the wallet even if you already own all the coins you want to redeem.

If backing decreases between review and execution so either minimum cannot be met, the transaction fails instead of paying less. A wallet change invalidates the review. For a submitted transaction with unknown outcome, use its saved signature to resolve status before making another attempt.

If either reserve is empty, or your burn is so small that one output rounds to zero, the current two-asset redemption cannot proceed. It has no “take only the remaining stock” option.

#Worked examples

These examples use invented balances to explain the formula. They are not quotes for any live coin. Real stock quantities, token decimals, and redeemable supply must come from the selected treasury.

Example A · A 1% redemption

A treasury has 1,000,000,000 redeemable coins, 100 stock A tokens, and 200 stock B tokens. Burning 10,000,000 coins consumes 1% of its supply.

The remaining 990 million coins share 99 A and 198 B. A subsequent holder uses that remaining supply and those remaining reserves, not the original numbers.

Example B · Creator contribution versus creator holdings

A creator holding 50 million of a billion coins has a 5% share under normal redemption. Separately, the stored treasury authority can use withdraw_all to transfer all remaining reserves without burning those coins. This explicit authority is independent of coin holdings.

Example C · Fees increase backing without minting coins

Suppose there are 1,000 coins backed by 10 A and 20 B. Reinvestment adds 2 A and 4 B without creating any new coins. Each coin’s backing changes from 0.01 A plus 0.02 B to 0.012 A plus 0.024 B. A holder of 100 coins still owns 10% of the supply, but that share now represents more stock tokens.

Example D · A premium is not extra reserve money

If all stock reserves are estimated at $300 and a holder burns 2% of the recorded supply, the illustrative stock value received is about $6, before fees and changes in prices. A market valuing the coin supply at $10,000 does not turn that 2% redemption into $200 of stocks. Trading valuation and reserve valuation are separate measurements.

Example E · Small balances and rounding

Assume a stock reserve contains 101 raw units and you redeem 1% of supply. The contract calculates 1.01 raw units and transfers 1. The fractional raw unit remains in the reserve. If the other stock would yield less than one raw unit, the entire redemption is rejected. The last valid redeemer of all remaining stored supply receives the remaining reserve balances.

#Creator-fee reinvestment

Eligible new atomic launches can route Pump creator fees to a dedicated Stocked fee-policy address. The policy then uses collected fees to buy the same two selected stocks and deposit them into that coin’s reserves. This applies to the creator-fee portion collectible through the configured Pump and PumpSwap paths, not every fee paid by traders or fees from every possible trading venue.

The launch creator approves this policy when signing the launch. Existing coins and previously prepared transactions do not automatically acquire a new fee destination. Verify the policy for the specific coin before assuming it reinvests fees.

Collection and reinvestment are different stages

1. Accrue. Eligible market trades accumulate creator fees at the market’s fee accounts.
2. Collect. The keeper collects native SOL or wrapped SOL into the coin’s policy-controlled accounts.
3. Quote. When a batch is eligible, the keeper requests routes for both stocks and checks minimum outputs and price references.
4. Buy and deposit. One reinvestment transaction executes both stock swaps directly into the canonical treasury reserves. The coin supply stays the same.

Collection can succeed while the later stock purchase is waiting. Pending SOL or wrapped SOL is not included in stock-only redemption balances. It becomes stock backing only after successful reinvestment. If the second stock swap fails, the reinvestment transaction rolls back the first swap as well; the earlier collection remains separate.

How the two stock allocations are chosen

The original SOL stock budgets become the policy’s fixed allocation weights. A launch using 1 SOL for each stock reinvests equally. A launch using 3 SOL for stock A and 1 SOL for stock B allocates 75% to A and 25% to B. Integer allocation rounding goes to B. Both allocations must remain positive.

These weights do not continuously rebalance the market value of existing holdings. They direct new fee spending. Stock price changes can therefore move the portfolio’s current value weights away from its original budget weights. The dev-buy budget is not part of this stock allocation.

The platform does not receive a creator-fee share under this policy. The keeper funds its own transaction and account costs. The stock quantities received still depend on execution prices and route costs. Fees do not create a fixed yield, guaranteed frequency, or guaranteed growth in dollar value.

The authorized keeper selects prices and routes within the implemented checks. This is not permissionless execution or an independent-oracle guarantee. A stopped worker, insufficient operating SOL, stale prices, unsuitable routes, issuer restrictions, or network problems can delay reinvestment.

#Prices and valuations

The app uses Jupiter reference prices for stock valuation and Jupiter routes for stock purchases. Dollar values are informational estimates. Reserve quantities and the redemption calculation come from on-chain accounts; a fresh dollar quote is not needed to calculate a stock-token fraction.

Base units and issuer display scaling

Token accounts store whole-number base units. For an asset with eight decimals, 100,000,000 base units represent one base-denominated token. The stock issuer may also apply a display multiplier through Solana’s scaled-UI extension. A wallet’s displayed amount may then differ from the base amount used by the transfer instruction.

The valuation code accounts for issuer scaling when translating reference prices to base-unit values. The program’s redemption formula still uses integer base units. A display multiplier is not a discretionary extra withdrawal right. See Solana’s scaled UI amount documentation ↗.

When a price is missing, stale, or rejected, the interface should not present it as a current valuation. Trading may be thin when the referenced stock market is closed. Available quotes can differ from the last published stock price, and selling redeemed stock tokens is a separate trade with its own fees and liquidity.

#Read a coin page

A verified coin page connects a mint to a treasury decoded from the Stocked program. It presents the available coin name and ticker, the stock pair, current reserve quantities, stored redeemable supply, market links, and relevant on-chain accounts.

“Verified” here describes account checks, not an endorsement of the creator, an investment rating, or a guarantee of liquidity. A name comes from available token metadata; the full mint remains the identity. Missing metadata does not prove the treasury is invalid, and attractive metadata does not prove an arbitrary account is a treasury.

• Pump.fun link: opens the coin’s trading page for that exact mint.
• Coin mint link: shows supply, token program, transfers, and other public token data.
• Treasury link: shows the program-owned state account.
• Stock reserve links: show the token accounts whose balances fund redemption.
• Transaction links: let you inspect actual confirmed instructions and balance changes.

An index request can fail or temporarily lag even when an account exists. Compare the exact mint and transaction signature before concluding a launch failed. The website’s status labels are a presentation of fetched data, not a substitute for a finalized transaction outcome.

#Interrupted launches and recovery

The saved-launch panel preserves the identity and budgets of an in-progress launch. Continue that record using the same wallet and website origin. A browser refresh, a lost HTTP response, and an expired unsigned transaction are different conditions; none alone proves that a signed transaction failed.

What is saved

Start over does not reverse a confirmed transaction. The application blocks discarding an unresolved signed attempt until its outcome is checked. Once an atomic launch is confirmed failed, start a fresh record rather than trying to continue the failed one.

Atomic preparation uses a server-side record protected by a random recovery capability. The browser retains local launch information and its protected mint key. After approval, the exact signed transaction is saved locally and durably before broadcast. Resuming should resend those same signed bytes when appropriate, rather than quietly asking for a new financial approval.

A copied wallet address alone does not grant access to another wallet’s atomic recovery record. Nevertheless, browser storage and recovery capabilities are sensitive. Do not share browser storage exports, recovery authorization material, or an unsigned/signed transaction just because somebody calls it a support request. Public transaction signatures and public account addresses are sufficient for many status checks.

Common messages

“Fresh route is below the reviewed minimum”

The market no longer meets the accepted stock output. Review a new quote for an unsigned attempt. Raising slippage automatically would change what you agreed to receive.

“Launch preparation is busy” or “still confirming”

A setup lease or previously submitted preparation is unresolved. Continue the same launch after status reconciliation. A busy message is not permission to duplicate the purchase.

“Prepared transaction expired”

The blockhash validity window ended. Unsigned messages can be refreshed only when the service rules allow it. Signed attempts require an outcome check first.

“Launch service needs configuration”

The website can be reachable while transaction preparation is unavailable. Program verification, metadata service, routing credentials, operating funds, and release switches are separate dependencies.

“Balance unavailable”

A balance request failed or could not be decoded. It does not mean the balance is zero. Check the account through an explorer or retry the read.

“Minimum not met” during redemption

The current transaction cannot deliver both reviewed stock minimums. Refresh the redemption instead of treating the older quote as guaranteed.

If browser storage was deleted, a mint key or recovery capability may be unavailable even though public transactions remain visible. The current flow does not promise recovery from every device-loss scenario. Inspect transaction history and the coin mint before creating a replacement launch.

#Locks and external burns

A lock restricts spending; it does not increase your share

A token lock usually moves coins to an account controlled by another program. Its release schedule, cancellation rights, and beneficiary are determined by that program and the specific lock. Locked coins remain part of the coin supply. Stocked cannot spend them with the creator’s ordinary signature.

To use the current redemption path, the holder needs eligible coins in an account the signing wallet controls. If a lock cannot be cancelled or released yet, holding its beneficiary rights does not make those coins immediately burnable. Updating Stocked does not itself change another program’s lock conditions.

Burning through Stocked is different from a generic burn

A successful Stocked redemption reduces both the mint’s supply and the treasury’s stored redeemable supply, while transferring both stock outputs. A generic token burn reduces mint supply but does not call the Stocked redemption instruction and does not transfer stocks. Solana documents the underlying token-burn behavior here ↗.

Sending coins to a “dead” address is not necessarily a token-program burn either. An inaccessible account may still contain tokens that are included in mint supply. An explorer label alone is not evidence that claims have been destroyed.

#Authority and security model

The stock reserve accounts are controlled by the treasury’s program-derived address, or PDA. A PDA has no ordinary private key that an administrator can reveal or import into a wallet. The owning program can authorize transfers using its instructions and seeds. See Solana’s PDA model ↗.

Pause switches have different scopes

Coin initialization requires positive supply, revoked mint and freeze authorities, and only the permitted metadata extensions on a Token-2022 coin. These coin restrictions are separate from the stock issuer controls described below. They do not imply all coin metadata is immutable.

The registry pause blocks new treasury initialization and fee reinvestment in the current program. It is not a universal freeze of every instruction. In particular, the retained redemption and withdraw_all instructions do not check that registry pause. Separate website release and worker switches can stop preparation or submission through the application.

A website being available does not make its program executable. The former treasury program is permanently closed; this differs from a registry pause. Its treasury instructions cannot run, even if historical account data remains readable. Independent markets and outside token locks have their own rules.

Upgrade and closure risk

The stored registry administrator and the program upgrade authority are separate roles. The current instruction set has no registry-admin rotation command; changing the program’s upgrade authority does not automatically change the administrator stored in the registry.

Revoked coin mint and freeze authorities constrain the coin token. The former treasury program was permanently closed, removing its execution path and leaving remaining program-controlled reserves inaccessible through it. Closure did not refund those stock reserves. A new deployment cannot automatically take authority over the old reserves.

Internal code review, automated tests, and fork simulations provide evidence about tested behavior. They are not the same as an independent third-party security audit and do not eliminate implementation, operator, key-compromise, or dependency risk.

#Risks and current limits

Use the following as a description of the current implementation, not a list of hypothetical future features.

• Authority withdrawal: holders share remaining reserves proportionally, but the stored authority can withdraw all backing without burning coins. There is no guaranteed reserve floor or refund of the original SOL purchase cost.
• Two-asset redemption: both outputs must be nonzero and satisfy minimums. There is no one-sided redemption when one reserve is empty or cannot transfer.
• External burns: generic burns do not synchronize the stored redeemable supply.
• Locks: outside vesting and locking contracts keep their own rules. The application does not provide a lock override.
• Price risk: both stocks and the coin can lose value. Backing is measured in assets, not a guaranteed dollar or SOL floor.
• Liquidity risk: routes can disappear, execution can fail, and a successful stock redemption does not guarantee those stocks can immediately be sold at the displayed estimate.
• Issuer risk: changes to token transfer controls, custody arrangements, corporate actions, or issuer terms may affect reserve assets.
• Custody and upgrade risk: program-controlled funds still depend on correct program code and the security of remaining administrative powers.
• Service dependency: transaction preparation relies on the RPC provider, metadata hosting, Jupiter, the sponsor wallet, and durable storage. Reinvestment also requires the keeper.
• Transaction constraints: the combined launch must fit message size, account, compute, and route constraints. A supported asset pair is not a guarantee that every budget or route can be combined.
• Browser recovery: clearing site data or changing origin can remove information needed to resume. A public wallet address is not a replacement for an atomic recovery capability.
• Legacy behavior: an older launch can have independent confirmed purchases and funding minimums. Follow that record rather than assuming it uses the latest atomic path.

The client rejects unsupported stock extensions, active transfer hooks, paused stock mints, and frozen default-account settings in the supported transaction path. These checks are distinct from the contract’s restrictions on the coin mint and from token-program enforcement. A stock issuer can change applicable controls after initial funding.

Availability and permitted use depend on location and issuer terms. This manual describes the software; it does not determine a reader’s eligibility or confer rights against an underlying stock issuer.

#Verify a coin on-chain

1. Start with the full coin mint. Obtain it from the confirmed launch and compare it with the market link. Do not match solely by name or ticker.
2. Find the treasury. Its address must derive from the Stocked program and the coin mint. Its account owner, discriminator, size, registry link, and mint fields must match the expected layout.
3. Check activation and stored supply. A prepared or initialized account is not necessarily an activated, funded treasury. Compare stored redeemable supply with the actual mint supply to detect external burns.
4. Inspect both canonical reserves. Each must be the treasury’s associated token account for the specified stock mint and correct token program. The token account’s internal owner must be the treasury.
5. Read balances in context. Record the slot and commitment of the reads. “Confirmed” and “finalized” are different levels of chain confirmation; values from different times should not be treated as an atomic snapshot.
6. Recalculate the expected stock outputs. Use each reserve’s raw amount, the burn amount in coin base units, and the stored redeemable supply. Divide with integer rounding down.
7. Inspect authority and issuer controls. Review program upgradeability and the actual token mint extensions, not only the website’s labels.

For a completed redemption, check the transaction’s success status, the Stocked program instruction, burned coin quantity, and recipient stock balance changes. A log line mentioning a transfer is not by itself enough if the overall transaction failed and rolled back.

For reinvestment, check a successful transaction that increases both canonical stock vaults while spending the policy’s fee balance. A successful fee-collection transaction alone proves collection, not stock purchases. A “live” badge is not a fixed dollar valuation.

#Program and account reference

Per-coin account derivation

The two reserves are associated token accounts derived from the treasury address, the stock mint, and its token program. The reserve’s token-account address is different from the treasury state address. Sending SOL to the program or treasury address is not a supported way to buy stock backing or redeem coins.

The current treasury state has a 178-byte serialized layout, including its eight-byte account discriminator. Its recorded supply is a 64-bit unsigned integer. Integrators must validate ownership and discriminators before decoding offsets and must not treat an arbitrary account with the same length as a treasury.

#Public data endpoints

The website exposes the following read endpoints for its current interface. They are rate limited and should be treated as application endpoints, not a versioned third-party API with an availability guarantee. The blockchain remains the source of transaction and account truth.

Large raw amounts are returned as strings so clients do not lose precision. Use integer arithmetic for balances and minimum outputs. JavaScript’s normal floating-point numbers cannot safely represent every unsigned 64-bit token amount.

Mutation routes require the application’s validation and recovery protocol. Do not send arbitrary instructions to internal keeper routes or replay a saved transaction without understanding its state. The browser-facing RPC proxy exposes an allowlist of methods; its existence is not an unrestricted public RPC service.

A useful account-specific health request is /api/health?treasury=YOUR_TREASURY_ADDRESS. A successful HTTP response can still contain issues such as NEW_TREASURIES_PAUSED, EMPTY_ACTIVE_RESERVE, or EXTERNAL_COIN_BURNS_DETECTED. Read the returned fields rather than treating HTTP 200 as “everything is safe.”

#Frequently asked questions

#Glossary

Atomic transaction

A set of on-chain instructions that commit together or roll back together. Separate earlier transactions are outside that guarantee.

Associated token account (ATA)

The canonical token account derived for a particular owner, mint, and token program.

Backing

The stock tokens held in the coin’s verified reserve accounts.

Base units

The smallest indivisible units recorded in a token account. Decimals convert them to base-denominated token quantities.

Basis point (bps)

One hundredth of a percentage point. One hundred basis points equals one percent.

Blockhash expiry

The point after which a transaction’s recent blockhash is no longer valid for submission.

Bonding curve

The market mechanism used for a Pump coin before its applicable market transition. Its token holdings are still part of supply.

Burn

Permanent destruction of token units through the token program. A generic burn does not invoke Stocked redemption.

Canonical reserve

The specific associated token account the program recognizes as backing for a treasury and asset mint.

Creator fee

The fee portion assigned to the configured creator destination by an eligible market. It is not every trading fee.

Dev buy

The optional coin purchase made for the creator during launch, paid from a separate SOL budget.

Fee policy

A per-coin program account defining fee destination, keeper, allocation weights, and execution replay state.

Keeper

The authorized background service that collects and reinvests eligible creator fees.

Lookup table

An on-chain address list that reduces transaction message size. A frozen table cannot later be managed through an authority.

Mint / contract address (CA)

The unique Solana address identifying the coin or stock token. Its name and ticker are not unique identifiers.

PDA

A program-derived address whose authority is exercised by program instructions rather than an ordinary private key.

Redeemable supply

The supply recorded in the Stocked treasury and used as the redemption denominator. It may differ from current mint supply after external burns.

Reserve value / NAV

An estimate of asset value derived from reserve quantities and reference prices; it is not the coin’s guaranteed sale price.

Signature

The identifier of a signed Solana transaction. It lets you investigate a submission independently of the website response.

Slippage

The permitted deterioration from an expected execution result, constrained by transaction minimum outputs or maximum input.

Slot

A Solana ledger scheduling unit used to associate reads and some deadlines with chain progress; it is not a fixed wall-clock promise.

Treasury

The Stocked state account defining a coin’s stock pair and recorded supply, with authority over its canonical stock reserves.

Wrapped SOL (WSOL)

SOL represented in a token account for token-program operations and routes. Pending WSOL in a fee policy is not a stock reserve.

#Sources and scope

This documentation was checked against the application’s launch, fee-policy, redemption, recovery, and account-decoding implementation on 4 September 2026. It does not claim that historical test balances, service switches, or a previously deployed binary remain current forever. New versions should be reviewed before relying on changed behavior.

The formula and authority descriptions refer to the retained source, including withdraw_all. Supply synchronization, a custom issuance ratio, an automatic refund of the original SOL purchase cost, a lock override, and migration of the old reserves are not implemented. The former deployment is closed.

• Solana · Transaction execution ↗
• Solana · Program-derived addresses ↗
• Solana · Token burns ↗
• Solana · Scaled display amounts ↗
• Solana · Deployment, upgrades, and closure ↗
• Jupiter · Quote semantics ↗
• Pump · Official program documentation ↗
• xStocks · Product legal overview ↗
• xStocks · Risk disclosure ↗

For a specific coin, start with its mint, treasury, and transaction signatures. Those public records let you distinguish a user-interface problem, an unconfirmed transaction, a reserve change, and a limitation of the economic design.