How HOLDONSOL.com works.

HOLDONSOL.com is an interface and incentive layer for supported Solana tokens in the Pump ecosystem. A qualifying purchase buys tokens through an official market route, places the purchased tokens into a position, and reserves a base rebate in the same transaction. Keep that position open for 20 minutes of on-chain time and its base rebate becomes eligible to vest.

The token and the reward position are different things. The token has a market price that can rise or fall. The position records a particular purchase, its locked token amount, its eligible principal, its unlock time, and its reward rights. Holding a token in a normal wallet does not by itself create this position.

1. Buy and reserve

   A 4% HOLDONSOL.com entry fee is allocated when the qualifying buy succeeds. The program reserves a base rebate equal to 2.5% of eligible principal. The actual newly purchased tokens enter your position vault.

2. Let one clock run

   The position records an unlock time 1,200 seconds after its on-chain opening. Every additional purchase creates its own position and clock.

3. Choose what happens next

   Before unlock, return your tokens through an early exit and forfeit the base rebate. At or after unlock, claim the base, withdraw the tokens, or keep them locked and explicitly activate variable bonus participation.

One SOL is 1,000,000,000 lamports. Accounting uses integer lamports and floors percentage calculations. UI summaries may display four decimal places; transaction review and on-chain records retain the precise amounts. A displayed 0.0000 SOL can therefore be a small nonzero amount.

For a 1 SOL gross buy, eligible principal is 0.96 SOL. The base is 0.024 SOL, or 2.4% of the gross input. The maximum additional bonus is 0.0528 SOL, and the combined lifetime ceiling is 0.0768 SOL. These are upper bounds and accounting amounts, not expected profit, an APY, or a repeating twenty-minute payout.

• Use a supported token and the qualifying Buy & hold transaction through this interface or an equivalent correctly constructed protocol transaction. A successful ordinary purchase on another interface does not reserve a HOLDONSOL.com rebate.
• The route must verify official Pump provenance or the canonical PumpSwap pool. A token appearing in a wallet, or a look-alike liquidity pool, is not enough.
• V1 uses native SOL for gross input and reward payouts. WSOL appears as the quote identifier and may be used inside external market instructions. The current launch interface offers SOL only.
• Supported token programs are legacy SPL Token and a restricted Token-2022 configuration. Mints with a freeze authority or unsupported extensions are rejected. Transfer hooks, transfer fees, permanent delegates and similar unsupported behavior must not be assumed compatible.
• Have sufficient SOL for the purchase, network fee, account creation and any other amounts shown in review. The gross buy amount is not necessarily the total wallet debit.

Check the network before connecting or signing

Solana mainnet and Devnet are separate networks with separate balances and deployments. A Devnet preview uses test assets; it is not evidence that a mainnet deployment is live. Match the network shown by the application with the account and transaction presented by your wallet. Explorer links include the selected network.

This guide describes the current V1 implementation reviewed on 14 September 2026. The accompanying design preview was on Devnet, with mainnet signing and deployment deferred. This dated statement is not a permanent deployment-status feed. Verify the current application network and deployed program before any future production use.

1. Find and identify the token

   Open Discover, search by token name, symbol or mint, then open the token page. Compare the full mint address with the asset you intend to buy. Names and images are not unique identifiers.

2. Connect the intended wallet

   Choose Connect wallet and approve account access in a compatible wallet. This gives the page a public account address; it does not approve a buy, claim, or token launch.

3. Enter a gross SOL amount

   Use Buy & hold. The panel previews the entry fee, eligible principal and reserved base rebate. It cannot promise a final token quantity before a live quote is prepared.

4. Choose slippage protection

   The current interface offers 0.5%, 1%, 3% and 5%, with 1% as the default. A tighter bound may make a moving-market trade fail; a looser bound permits a worse fill. Slippage is not another fee.

5. Request and read the transaction review

   Review transaction builds a live quote and simulates the complete transaction. Check wallet, network, mint, external fees, minimum received tokens, account rent, network costs and the reserved rebate.

6. Approve the transaction in your wallet

   Only approve if the actual wallet request matches what you intend. A prepared review alone does not send funds. If the quote expires or your wallet changes, close it and prepare a fresh review.

7. Verify confirmation and the position

   After submission, the interface checks confirmation. Open the transaction explorer if needed, then inspect My positions. Finalized indexing can arrive after the transaction is already confirmed.

The atomic purchase contains the protocol opening, the verified external buy, and the matching finalization. If the market trade or token custody step fails, the position and protocol fee transfers do not partially succeed. Solana network fees can still be charged for an executed failed transaction; an error is not a promise of zero total cost.

• Solana transaction behavior

  Official explanation of atomic state changes and network fees on failed transactions.

The entry fee first separates the trade budget from the reward and revenue allocations. The base allocation is calculated from eligible principal. The remaining allocations use gross input. The two denominators must not be mixed.

G = gross input in lamports
F = floor(G × 400 / 10,000)
P = G − F
B = floor(P × 250 / 10,000)

G = P + F
F = base + treasury + bonus allocation + referral + safety

When no referrer is supplied, the 0.001 SOL referral allocation in this example goes to Treasury, making Treasury 0.011 SOL. It does not reduce your fee or increase your rebate. An invalid supplied referrer causes rejection; it is not silently ignored. The current Buy & hold UI does not include a referral field, although the API and protocol support a validated referrer. Do not assume that a referral-link reward program is available in the UI.

For arbitrary lamport amounts, Treasury receives floor(G × 1%), the bonus allocation is floor(G × 0.2%), and the referral allocation is floor(G × 0.1%). Safety receives the entry fee remainder after the other allocations. This preserves every lamport, including rounding dust. The nominal Safety allocation is 0.3% of gross before rounding and any idle-pool routing.

A referrer must be eligible under the on-chain account checks and cannot equal the buyer. This is address validation, not proof that two wallets belong to different people. No identity-level referral protection is implied.

The review attempts to estimate a total wallet SOL change from simulation. If chain state advances during that calculation, it says that the wallet simulation will show the final total. A quick fee preview is not a substitute for that full review.

Account rent can dominate a very small purchase. A minimum accepted buy size does not mean that the reserved rebate exceeds the cost of creating a permanent Position account. Repeated tiny purchases also create independent positions, which can each incur storage and transaction costs.

Closing a fully settled position can close its token vault and return that token account’s rent when eligible. It does not delete the permanent Position account or refund its storage balance. A normal token withdrawal should not be described as automatically returning every setup cost.

• Solana network fees

  The network distinguishes a base fee from optional prioritization fees. The live transaction review determines the applicable amounts.

Your purchased tokens are held in a token account whose authority is the program-controlled position. The wallet still identifies the owner who can request eligible actions, but the locked tokens are not a freely spendable balance in the wallet’s ordinary token account. Calling the wallet non-custodial must not hide this temporary program custody.

The position stores opened_at and unlock_at. Unlock is opening plus 1,200 seconds, using Solana’s Clock. Closing a tab, disconnecting the wallet or turning off a phone does not pause or reset the recorded unlock time. A later purchase does not extend the earlier purchase’s timer.

Purchase A opens at 12:00:00 → eligible at 12:20:00
Purchase B opens at 12:07:00 → eligible at 12:27:00

The times above are illustrative on-chain timestamps.
A and B keep separate token custody and rebate accounting.

The visible countdown is an estimate based on a sampled on-chain time, not your device wall clock. The current interface stops extrapolating after a clock error or more than 60 seconds without a fresh sample. A frozen countdown indicates an unavailable time estimate, not a new lock imposed by the browser.

Reaching zero makes a position eligible for on-chain vesting; the browser itself cannot change the account. A vest, claim, withdrawal or bonus-activation transaction can apply the eligible state on-chain. An OPEN_LOCKED record can therefore briefly appear as Ready to vest after its recorded unlock time.

Base-claimed and bonus-active flags also matter. Claiming a base rebate does not necessarily withdraw the tokens or end bonus participation. A WITHDRAWN position can still have an unclaimed vested base. A closed record can retain a history of an earlier forfeiture; closing it does not restore a lost reward.

Buttons are shown from the account state and the available chain-time estimate. The program checks authority, time, status and balances again during execution. A visible button is an invitation to prepare a checked transaction, not a guarantee that changing state will still allow it.

Claim the base and continue holding

At or after unlock, claim_base can apply vesting and pay the reserved base to the position owner. It does not require you to withdraw the tokens. If you later activate or continue bonus participation while the tokens remain locked, claiming the base does not create a second base entitlement.

Withdraw the tokens and claim the base later

withdraw_tokens checks the on-chain unlock time and can apply vesting automatically. It returns the position’s token amount. If bonus participation was active, withdrawal reconciles and settles the funded bonus, pays the eligible accrued amount and removes the position’s active shares. A vested base that was not claimed remains independently claimable.

Leave both tokens and base in the position for now

You do not need to keep the browser open or claim at precisely twenty minutes. The current V1 base-claim logic has no short claim-expiry window. Normal network availability and your ability to sign as the owner are still required. Additional waiting does not multiply the base rebate.

Combined and cleanup actions

The protocol and preparation API also support claim_and_withdraw and close_position. The current general positions UI presents individual claim, bonus and withdrawal actions rather than a universal one-click batch flow. Do not assume that every lower-level instruction has a dedicated button on every page.

Closing requires an early-exited or withdrawn position, no locked tokens, no active or accrued bonus, and either a claimed base or a base forfeited through early exit. Any donated vault tokens are returned before the token vault closes. The permanent Position account remains.

• Claiming base transfers SOL; it does not sell tokens.
• Withdrawing transfers tokens; it does not itself sell them for SOL.
• Selling already unlocked tokens does not revoke a vested base rebate.
• Each purchase has its own claim accounting. Claims are not automatically combined across every position.
• A repeated successful base claim is prevented by the position’s recorded claimed state.

Before unlock, early_exit returns the actual tokens held by that position to the owner’s token account and permanently removes the position’s unvested base entitlement. It does not add an early-exit charge to the original token quantity in the ordinary supported-token flow; the economic loss is the forfeited rebate, plus the transaction costs and any market loss on the tokens.

The initial purchase and its already charged fees are not reversed. A later new buy opens a new position with a new clock and new costs. It does not revive the early-exited position or transfer its old waiting time.

For arbitrary lamport values, the bonus leg is floor(forfeited base × 80%) and Safety receives the remainder. If the token has no active bonus shares, that bonus leg also goes to Safety. Merely owning tokens, or having a still-vesting position, does not make someone an active bonus participant.

At or after the exact unlock timestamp, the early-exit path is no longer the appropriate route. Use the eligible vesting/withdrawal paths, which preserve the base entitlement. The program’s clock decides this boundary even if the browser estimate differs.

The Exit Pool is a token-specific bonus mechanism backed by assets actually received. To participate, keep the purchased tokens in their position after vesting and explicitly activate bonus participation. Reaching twenty minutes alone does not automatically add shares. Tokens sitting in an ordinary wallet do not qualify for bonus shares.

A position’s shares equal its eligible principal. They are not determined by the token’s current market value, the number of tokens held, social reputation, or how many browser sessions are open. The pool distributes new funded amounts proportionally across the active shares for that token.

This example assumes both positions were already active before the allocation, neither had reached its lifetime bonus cap, and there are no other active shares. Joining afterward does not entitle a new position to this earlier distribution. Future distributions change as participants join or withdraw.

Each position starts from the token pool’s current accounting checkpoint. Direct deposits are reconciled before new shares are added. This prevents a newly activated position from claiming historical funding that belonged to earlier participants, or funding that arrived while no participants existed.

Claiming available bonus advances the checkpoint and records what has already been paid. It does not reset the lifetime cap or create a new twenty-minute base reward. Withdrawing removes the shares and ends that position’s participation; continuing to hold the returned tokens elsewhere does not keep it active.

All bonus allocations received while there are no active shares go to Safety. They are not an accumulating giveaway waiting for the first activator. A large historical total of allocations is therefore not evidence of a large current Exit Pool balance.

Maximum additional bonus = floor(eligible principal × 550 / 10,000)
Base rebate = floor(eligible principal × 250 / 10,000)

Base + lifetime bonus ≤ 8% of eligible principal
Repeated claims do not reset either amount.

If a position reaches its bonus cap, extra accrual cannot increase its entitlement. Its shares are not automatically removed: they remain in the denominator until withdrawal, and cap excess is not immediately redistributed to uncapped positions. The code caps settlement against bonus already claimed and accrued. When the final active participant leaves and remaining participant liabilities have been settled, residual assets move to Safety and the index resets.

A permissionless reconciliation path recognizes direct transfers above the vault’s rent and already accounted assets. Reconciliation also occurs in activation and settlement-related actions. The same deposit cannot be counted repeatedly as new funding.

The program uses a cumulative fixed-point index rather than looping through every holder on every deposit. The technical appendix explains the arithmetic. For a user, the relevant facts are actual funding, your activation checkpoint, your share, your lifetime cap, and a transaction that settles the claim.

Spendable base assets = reserve SOL balance − required rent
Outstanding liability = reserved, unpaid, unforfeited base claims

If liability > 0:
  coverage = spendable base assets / liability
If liability = 0:
  display “No liabilities” rather than a meaningful coverage ratio

The UI obtains the base reserve reading on-chain and links to the reserve address and observed slot. Reserving a new base increases its liability; claiming or forfeiting it reduces that liability. Vesting alone does not remove an unpaid liability. The same reserve is shown on different token pages because base backing is shared, while the Exit Pool is specific to the selected token.

A coverage reading at or above 100% means observed spendable base assets cover the recorded base liabilities at that sample. It says nothing about token liquidity, market losses, future market prices, malicious upgrades, or a particular future bonus. If the RPC reading fails, an old sample must be treated as last verified data.

The current instruction set has no admin sweep of the base reserve or position token custody. Treasury and Safety have distinct administrative withdrawal paths. Safety sweeps respect a configurable floor, but the protocol authority can change that floor. These are properties of the current code; the separate program upgrade authority remains a trust assumption.

Once tokens have been returned to your wallet, you can choose a supported sale route. The HOLDONSOL.com Sell panel sells unlocked wallet tokens. It does not reach into an active position vault, automatically perform an early exit, or claim an outstanding rebate for you.

Available to sell reads the finalized balance of the connected wallet’s canonical token account for this mint. The 25%, 50%, 75% and MAX controls derive exact raw token units and round partial percentages down. Tokens still held in a position vault are excluded until withdrawal, and a frozen token account cannot prepare a sale.

The optional router measures the external sale’s actual proceeds and charges 2%. Treasury receives floor(50% of that router fee), the token’s bonus allocation receives floor(30%), and Safety receives the remainder. With no active bonus shares, the bonus allocation also moves to Safety.

Optional means choosing this sale route. Its 2% router fee is mandatory when the route is used.

The example starts with proceeds measured after the external trade’s effects; it does not assume a fixed Pump fee. In a native Pump sale, the router measures the owner’s net SOL increase during the external operation. In a PumpSwap sale, it measures newly received WSOL, excludes pre-existing WSOL and returned token-account rent from the fee base, then unwraps the quote account. Pre-existing WSOL in that account can also become native SOL without being treated as new sale proceeds for this fee.

A direct sale elsewhere does not incur the HOLDONSOL.com router fee, but the chosen market can still charge its own fees and has its own execution risks. There is no claimed mandatory HOLDONSOL.com token transfer tax. After vesting, such a sale does not cancel the position’s base entitlement. The sale price is independent of the rebate.

A supported token can begin on a Pump bonding curve and later graduate to the canonical PumpSwap pool. The SDK reads the canonical curve’s completion state and selects the supported official route. The token page labels market status from available verified data; an Unknown label is not permission to choose an arbitrary pool.

Graduation changes where new trades execute. It does not merge old positions, reset their clocks, change their recorded eligible principal, or automatically cancel vested base rights. Claims and withdrawals depend on the position and token accounts rather than requiring another market trade.

Supported existing Pump tokens can be registered by the protocol when the canonical provenance and mint checks pass; a token does not have to have been created through this UI. However, registration does not retroactively award rebates for earlier ordinary buys and does not automatically install the configured creator-revenue split.

If upstream accounts, fee layouts, token features or lookup-table configuration cannot be verified, preparation can stop instead of presenting a substitute quote. A route-availability error should be resolved from current state. It is not a reason to bypass simulation or loosen every protection.

1. Describe the token

   Open Launch token. Add an image, name, ticker and description. Optional HTTPS project links help identify the project but do not prove its safety. The Preview panel reflects your input and remains marked Not launched.

2. Select the creator account

   Connect the wallet that should be the creator and review the SOL quote asset. A local preview is not a mint, and typing an address into explanatory content does not authorize a creator action.

3. Provide public metadata

   Use the configured image-upload flow or supply an existing public HTTPS metadata URI. An upload may request a message signature authorizing one public metadata upload. The signed message identifies the wallet, nonce and upload purpose; it does not cryptographically bind the image or metadata content. This is separate from the later transaction approval.

4. Choose an optional creator Buy & Hold

   The launch form can remember a SOL amount and slippage limit for a creator dev buy. The buy is prepared only after creation succeeds, as a second transaction with its own review and wallet approval. It opens a normal 20-minute HOLDONSOL position and is not guaranteed to be the first market buy.

5. Review the complete launch

   The application prepares official Pump creation, protocol registration and the supported fee-sharing configuration, then simulates the transaction. Check the mint, creator, metadata, costs and requested split.

6. Approve and verify

   Approve the actual launch transaction in the creator wallet only if it is correct. After confirmation, the launch screen follows finalized indexing and Discover shows Newest first. Open the resulting token page and verify the creation transaction and finalized sharing state.

Public metadata may persist outside this website. Do not upload secrets, seed phrases or private personal information. A supplied HTTPS URI is not automatically immutable, and the preparation endpoint does not fetch and prove that its contents match every field you typed. Verify the destination and its content before using it.

The creation flow can generate a temporary signer for the new token mint. This is separate from your wallet’s private key, which remains in the wallet. The existence of that mint signer does not let the application spend as your connected wallet without the wallet’s authorization.

The current full create, register and creator-sharing transaction is already close to Solana’s packet-size limit. Adding the HOLDONSOL buy-position instruction group to that same transaction exceeds the limit with the deployed lookup table, so the interface presents the creator buy as an explicit second approval instead of claiming atomic launch-and-buy behavior.

A confirmed creation can take a short time to reach finalized commitment and the index. The launch result polls for that finalized record for approximately thirty seconds. If it reports a delay, the creation transaction may still be valid; verify the mint and transaction on-chain rather than submitting a duplicate launch.

If upload succeeds but the launch transaction is cancelled or fails, the public upload may still exist while no token was created. If upload infrastructure is unavailable, the current interface offers an existing metadata URI path; that path still requires a valid launch transaction and its account costs.

These percentages divide creator revenue that Pump actually generates under the applicable sharing configuration. They are not percentages of token supply, market capitalization, gross trading volume, or a promised daily income. If no eligible creator revenue is collected and distributed, this source contributes no reward.

The current launch builder requests the supported official sharing flow. Requested configuration is not the same as finalized on-chain configuration. The indexer only publishes a finalized status after verifying the relevant official account, its mint and state, revoked normal sharing administration, and the exact intended recipients and percentages.

The official sharing lifecycle can finalize ordinary recipient edits, but HOLDONSOL.com cannot eliminate the upstream protocol’s privileged takeover or upgrade powers. Existing registered tokens may show unverified sharing; do not infer the 40/30/20/10 allocation merely because a token appears in discovery.

Actual payments directed to a bonus vault must be reconciled into its funded accounting. With no active bonus shares at reconciliation, the normal idle-pool rule applies. The creator’s own share and protocol balances are separate from a user’s base claim.

• Pump creator fee sharing

  Official lifecycle and recipient-distribution instructions. Applicable to coins using the relevant sharing configuration.

The active preparation endpoint gives a review a 30-second expiry from preparation. This is a product quote limit, separate from the network’s recent-blockhash validity. Before requesting the wallet signature, the UI checks quote age, the selected cluster string and the wallet address recorded in the summary. Changing accounts or networks requires a new review.

The normal application review trusts the server to construct the transaction and summary. It does not independently decode every instruction and cryptographically prove that each displayed statement matches the bytes. Your trust boundary includes the served frontend, the preparation service and the actual wallet approval screen. Review the wallet request itself, not just the page’s reassuring labels.

After submission, the UI polls approximately every two seconds for up to thirty attempts. It accepts confirmed or finalized status and then waits for the finalized index to refresh. If confirmation remains uncertain, it directs you to the explorer rather than declaring a definite failure. Network time and provider delays can make the elapsed wall time longer than the nominal polling interval.

• If simulation is rejected before wallet submission, this preparation flow has not sent your transaction. Recheck current state, amounts, rent, market support and slippage.
• If a submitted transaction fails on-chain, the requested state changes are reverted, but network transaction fees can remain charged.
• If the wallet cancels before submission, no completed purchase should be inferred from the abandoned review.
• If a signature exists but the UI is uncertain, inspect that exact signature before preparing a duplicate economic action.
• Never provide a seed phrase or wallet private key to a support chat or to a form in this application.

The percentages named Reached 20 minutes

The discovery-card indicator compares observed vested positions with vested plus early-exited positions. The profile indicator uses vested records divided by its available recorded positions and requires at least five records. The leaderboard survival category ranks tokens, not wallets, and also requires at least five positions. These measures have different populations; they should not be treated as the same universal success rate.

Claimed, reserved and forfeited

Claimed means an actual recorded payment. Reserved means a remaining allocation, which may still be unvested. Forfeited means the position permanently lost that base entitlement through early exit. The portfolio’s effective claimed rebate divides claimed base plus claimed bonus by lifetime eligible principal. It does not include unrealized token gains and is not an annualized return.

History is bounded

The current public activity endpoint returns up to 50 events, and the chart endpoint returns up to 250 trades. Profile launches are found from the available recent activity. A missing older event or launch is not proof it never happened. Use the relevant transaction and account explorer when a complete record is needed.

The program is the source of execution authority. RPC supplies on-chain observations and transaction simulation. The indexer organizes finalized events and account state into queryable history. The web interface combines these readings with short-lived estimates. A database row or browser countdown cannot authorize a claim that the program rejects.

If a claim is confirmed but the old position is still visible, first inspect its transaction status and allow the finalized index to catch up. If the index is stale, avoid treating cached totals as a new quote. Base and bonus eligibility are enforced again by the program in any subsequent transaction.

A: Claim after a 1 SOL buy

The buy allocates 0.04 SOL to the entry fee and 0.96 SOL to the external market budget. It reserves 0.024 SOL for base. After 1,200 on-chain seconds, an eligible claim pays that 0.024 SOL. You still hold the purchased token amount unless you separately withdraw and sell it. Account and transaction costs are additional.

B: Leave after seven minutes

The same position early-exits before unlock. Its tokens return to your wallet, its 0.024 SOL base is forfeited, and its purchase price is not refunded. With active bonus participants, 0.0192 SOL is allocated to the token pool and 0.0048 SOL to Safety; without active participants all 0.024 SOL goes to Safety.

C: Base rebate, with different market outcomes

This table assumes the listed sale proceeds are already net of any trading/router fees used in that hypothetical sale. It excludes network fees and account rent, assumes no bonus and makes no price forecast. Include those additional costs to calculate a complete wallet-level result. It deliberately does not double-count external buy fees already paid within the 0.96 SOL trade budget.

D: Activate bonus after everyone else has left

Being the next activator does not let you collect allocations that arrived while no shares were active. The program routes that idle funding to Safety before adding new shares. Your eligibility begins from the current index and depends on later funded allocations.

E: Claim base first, withdraw later

Claiming the 0.024 SOL base once does not reset the clock or the bonus cap. If you activate bonus while the tokens remain locked, you can participate within the 0.0528 SOL additional lifetime cap. Withdrawing later settles the eligible accrued bonus and removes those shares. A further claim cannot recreate the original base allocation.

An error message should be read together with whether a transaction signature exists. Before submission, a failed preparation is not a completed on-chain action. After submission, a UI timeout alone is not proof of failure. If seeking help, share the public network, mint, position address and transaction signature rather than secret wallet material.

The selected operating model uses direct mobile-wallet roles rather than a multisig requirement. Address separation is not a threshold approval system. Do not infer an enforced quorum, automatic timelock or hardware-wallet requirement from the presence of multiple role addresses. The deployed accounts determine the actual authority assignments.

Under the current code, pausing blocks mint registration, new position opening and the optional sell router. It does not gate existing-position vesting, claims, bonus actions, early exits, withdrawal or closure. This describes the current pause flag, not a guarantee against all network failures, external token failures or later upgrades.

Treasury and Safety sweeps can only pay the Treasury recipient configured at initialization. The Safety floor can be lowered to zero by the protocol authority. Ordinary configuration cannot change the Treasury recipient.

V1 economic constants are not editable by a routine economic-configuration instruction. That is narrower than saying the entire system is immutable: an authorized program upgrade can replace the code. The configured Safety floor is also not immutable and can be lowered by the protocol authority.

• Market and liquidity risk: token value can fall sharply or to zero, and a sale may not fill at the expected price.
• Execution risk: slippage, account changes, congestion, expired quotes and upstream updates can change availability or outcomes.
• Contract and authority risk: bugs, compromised role wallets or malicious upgrades can affect custody and claims.
• Wallet and interface risk: phishing, wrong networks, wrong mints and misleading requests can cause losses even when the protocol behaves as coded.
• Data risk: cached, incomplete or unavailable history can mislead a decision if treated as a fresh full-chain view.

Read the application’s risk disclosure before use. This mechanics guide is not an independent audit report, proof of current mainnet readiness, insurance agreement, or investment recommendation. The product’s legal templates and operating disclosures must be completed separately where required.

Gross input

The SOL amount selected for the qualifying buy, before the HOLDONSOL.com entry fee.

Eligible principal

Gross input minus the entry fee; the external trade budget and the denominator for base and bonus caps.

Base rebate

The funded allocation that vests after the position’s hold period and can be claimed once.

Vesting

The on-chain transition that makes the base entitlement irrevocable by ordinary later token withdrawal or sale.

Position

A permanent on-chain record for one purchase, including owner, mint, custody amount, timer and reward state.

Token vault

The token account controlled by a position, holding the purchased tokens during custody.

Exit Pool

The token-specific funded bonus vault and its active-share accounting.

Bonus shares

The eligible-principal weight of an explicitly activated position.

Checkpoint

The index value from which a position’s newly accrued bonus is calculated.

Reconciliation

Recognition of newly arrived vault assets that have not yet been included in bonus accounting.

Forfeiture

Permanent loss of the unvested base allocation through a successful early exit.

Lamport

One billionth of a SOL, used as the integer unit for native-SOL accounting.

Basis point / bps

One hundredth of one percent. 250 bps is 2.5%; 10,000 bps is 100%.

Slippage tolerance

The permitted difference from a quote used to construct a minimum-output bound; it is not a fee.

Rent balance

SOL held to support on-chain account storage; recoverability depends on whether the account can actually be closed.

Mint

The token’s on-chain identifier. Symbols and images are not unique substitutes for a mint address.

PDA

A program-derived address used for controlled accounts such as reserves and positions.

ATA

An associated token account for a particular owner, mint and token program.

WSOL

Wrapped SOL represented in a token account for compatible external market operations.

Confirmed / finalized

Different transaction commitment stages. The UI can accept confirmation before its finalized history index updates.

RPC / indexer

RPC provides chain reads and transaction interfaces; an indexer organizes verified chain activity into application queries.

Upgrade authority

The authority able to replace upgradeable program code, separate from a routine pause or configuration action.

Accounts and atomic boundaries

The main protocol accounts are GlobalConfig, per-mint MintConfig, per-owner Position, the shared QuoteReserve, per-mint BonusPool, and separate Safety and Treasury vaults. Each position has a canonical token vault. Position IDs are scoped by owner and remain consumed after closure because the Position record is retained.

Optional supported account / compute setup
  ↓
open_position(owner, position_id, gross_input, min_tokens_out)
  ↓ immediately
Official supported Pump / canonical PumpSwap buy
  ↓ immediately
finalize_position(owner, position)
  ↓
Optional supported cleanup

The central instructions inspect and verify their adjacency, relevant accounts, external program and instruction identity, exact trade budget and minimum output. Finalization records the new buyer-token balance delta and transfers that purchase output into the position vault. The atomic triplet cannot be split across multiple transactions merely to fit a size limit.

Bonus arithmetic

Q = 2^128
Δindex = floor(newly accounted bonus assets × Q / total active shares)
earned = floor(position shares × (index − checkpoint) / Q)
remaining cap = floor(principal × 550 / 10,000) − claimed − accrued
settled = min(earned, remaining cap)

Update checkpoint after settlement.
Move actual funds before indexing a protocol funding operation.

The implementation stores the index in four little-endian u64 limbs and uses checked wider arithmetic. This supports fixed-point distribution without treating floating-point browser calculations as authoritative. Bonus accounted assets are constrained by spendable vault assets. An empty active-share set is handled by the Safety routing rule instead of division by zero.

Authority and version records

Initialization sets the protocol authority, guardian, Treasury recipient, initial pause state and Safety floor. Routine configuration does not change V1 economic constants. Protocol-authority transfer uses propose-and-accept steps. Program upgrade authority is a distinct loader-level capability and must be checked separately.

Verifying a specific position

• Identify the exact network, program, wallet, token mint and position address.
• Find the successful opening transaction and verify the actual purchased token amount, gross input and eligible principal.
• Read the recorded opened_at and unlock_at rather than reconstructing them from browser time.
• Check the base vested/claimed fields, status, token custody and bonus active/checkpoint/claimed fields.
• Use the transaction signature, source program, event index, slot and commitment when comparing indexed history with the chain.
• Compare reserve assets excluding rent with the corresponding recorded liabilities; do not substitute Treasury or token market value.

The ordinary guide and API examples do not authorize an operator deployment or change a wallet role. The separate administrative mobile-signing workflow has its own request formats and checks; it is not the same approval path as the normal Buy & hold transaction review.

This guide was checked against the active code paths in the local HOLDONSOL.com workspace on 14 September 2026. The implementation map below is for maintainers who need to verify a rule. Internal package names, PDA seeds and the historical hold20 program name remain stable through the product rebrand.

• Solana transactions

  Atomic instruction execution and transaction fundamentals.

• Solana fees

  Network fees and prioritization, distinct from application and external-market fees.

• Pump creator fee sharing

  Official sharing lifecycle, supported accounts and recipient distribution.

• Risk disclosure

  Product risk explanation; review alongside actual deployment-specific information.

Updating this guide should start from the current execution paths, not only from a previous README or a generic configuration constant. For example, the current normal review endpoint issues a 30-second expiry even though a general configuration field elsewhere is named for a 20-second quote age. Documentation must describe the path that users actually execute.

Protocol verification, a local UI test and a production release qualification are different forms of evidence. This guide explains mechanics and current interface limits. It does not convert historical test results, a compiled production candidate, or a Devnet preview into proof of a live, audited mainnet deployment.