# HYPED: deployment and operation **Status:** Onchain and irreversible. Not independently audited. Not affiliated with Hyperliquid or pump.fun. The Solana program is compiled and the complete flow is tested against a read-only snapshot of the actual mainnet Pump, PumpSwap, Fees and Mayhem programs. A historical deployment of the same bytecode exists on mainnet (see the Proofs section in `docs.html#proofs`); it is under re-audit, its infrastructure and ownership must be re-verified, and `dist/live-config.json` stays `enabled: false` until then. No coin is registered and no keeper is presented as live. ## Required public information and signatures - Treasury wallet for both 5% budgets (10% of creator fees total): `Cx64PYoAD5a61fds7vRjJsMPxd2AHkecBu62x1FC6biQ` (historical deployment, read-only verified; under re-audit). - A durable operator wallet. It initializes the program, publishes holder snapshots and signs buybacks. The program initialization requires this wallet to be the deployed program's upgrade authority. - Historical program (bytecode verified read-only on 2026-10-29): `7y3Y6hkaiRH73vr5EYXnCSYrRQyUpAwChJQ8bH3QXqL3`. - Frozen lookup table: `5CL1TjWVUr4WhDegKHmvMizAkhofsGHwCU8Ry7s5Je48` (75 addresses; historical, under re-audit). - SOL for program deployment, account rent and network fees. The preparation script queries rent instead of assuming a fixed USD cost. Keep wallet keys in your wallet or your own Solana CLI setup. Do not paste seeds or private keys into chat, configuration, source files or the website. `.local/` and keypair files are ignored by Git. ## Compiled artifact `artifacts/hype_roots_vault.so` is the tested SBFv3 build. Its SHA-256 and byte length are recorded in `dist/protocol-status.json`. The program has no hardcoded deployment address; all PDAs derive from the actual deployment address. Recompilation uses the locked Rust dependencies. ```sh npm ci npm run build:program npm run snapshot npm run test:onchain npm test npm run build ``` The build script uses Anza platform-tools v1.57 from `SOLANA_PLATFORM_TOOLS`, or the workspace-local tools installed for this project. The direct compiler invocation matches Anza's SBFv3 target and linker flags, without changing the computer's Rust installation. ## Mainnet activation 1. Open **Deploy with Phantom** (`deploy.html`) in a browser with the operator's Phantom extension or Phantom mobile browser. The currently configured operator is `Cx64PYoAD5a61fds7vRjJsMPxd2AHkecBu62x1FC6biQ`; the treasury recipient is `Cx64PYoAD5a61fds7vRjJsMPxd2AHkecBu62x1FC6biQ`. The same Phantom wallet pays and signs the program deployment and receives the treasury allocations. Program deployment creates the protocol infrastructure; token creation happens separately through Launch a coin. The page verifies the exact tested artifact and full Solana mainnet genesis hash, then reads the wallet balance, account rent and current fee quotes. The CLI shown below is an alternative. 2. Connect that Phantom account and review the next step. Approve upload-buffer creation, batches of up to eight 900-byte program writes, then the final atomic program creation and loader-v3 deployment. The 152,328-byte artifact takes 170 write transactions plus creation and final deployment. The page compares uploaded bytes against the tested artifact and skips already confirmed chunks when resuming. 3. Keep the public progress download when changing browsers. It contains account addresses and signatures only. Temporary buffer/program account keys are held only in browser memory and are discarded after account creation/deployment. The program address is generated for final deployment and can change before deployment if that browser session is lost. An existing unused buffer can be refunded to the same operator through **Review unused buffer refund**; this cannot close a deployed program. 4. Once the actual deployed bytes and upgrade authority are verified, choose **Continue to protocol initialization**. The program address is passed to `setup.html`. Review the exact current rent and network fees, then sign initialization, lookup-table creation, extension batches and freeze individually. Onchain operator and treasury are immutable after initialization. 5. Choose **Verify & download live-config.json** once every setup step is confirmed. Export requires the tested bytecode, treasury, operator and complete active frozen lookup table to match mainnet. 6. Replace `dist/live-config.json` with that exact exported file, rebuild and republish. The main app verifies the deployment again before enabling transactions. Never enable it by simply replacing `false` with `true`. Every money-moving signature is approved by the operator in Phantom. The deployment page refuses insufficient funds, altered wallet messages/signatures, stale review state, expired blockhashes or a wrong mainnet/build. Unknown transaction confirmations block additional signatures until a confirmed or finalized result is read; an RPC height or absent history never unlocks a replacement payment. Transaction validity uses isBlockhashValid directly because slots and block heights are different counters. Each reviewed deployment batch gets a fresh verified blockhash and simulation immediately before requesting wallet signatures. The upload buffer's rent is reused for permanent ProgramData at final deployment; it is not charged twice. Later program growth requires an explicit loader extension. The public browser RPC defaults to `https://solana-rpc.publicnode.com`, whose mainnet hash, balance queries, rent and fee queries have been verified from the browser. The official public mainnet endpoint currently returns 403 for these browser-origin requests. A browser-compatible public production RPC can be substituted; mainnet and account identities are checked again. The CLI fallback remains available through `scripts/prepare-deployment.mjs` (unsigned public transaction plan) and `scripts/enable-mainnet.mjs` (verified configuration). Both require the same public deployment information. Rebuilding the program marks release verification incomplete; run `npm run verify:release` before publication. ## Upgrading the deployed program `upgrade.html` upgrades the existing program in `dist/live-config.json` in place with the upgrade authority in Phantom. It refuses to start unless the deployed bytecode is the recorded previous build (`previousBuild` in `dist/protocol-status.json`), the connected wallet is the upgrade authority and the network is mainnet. It uploads the tested artifact to a temporary buffer (one creation, then 170 resumable 900-byte writes in batches of up to eight), then sends one Upgrade transaction signed only by the authority, which is also the spill account: the buffer rent comes back to the same wallet in that transaction. If a new artifact were larger than the existing ProgramData capacity, the page would add a separate ExtendProgram step first (at least 10 KiB, permanent rent). `upgrade.html?rollback=1` runs the same flow back to the previous build. `node scripts/upgrade-cost.mjs` prints the exact read-only mainnet quote. After the upgrade is confirmed, publish a `live-config.json` whose `programSha256` and `programBytes` match the new build; until then the app refuses the upgraded program. See `audit/fee-upgrade-plan-20261029.md`. ### One-signature express upgrade (owner's Mac) `npm run upgrade:express` (`scripts/express-upgrade.mjs`) serves `http://127.0.0.1:4293/`. The owner connects Cx64 in Phantom and approves **one** transaction. In that transaction Cx64: - creates and funds the upload buffer; - funds a local uploader key; - rotates the keeper delegation (on by default; `--no-keeper` turns it off); - temporarily hands the ProgramData upgrade authority to that uploader. Everything after the signature runs automatically from the Mac: - 170 buffer writes; - a hash check of the buffer; - one transaction that upgrades, returns the upgrade authority to Cx64 and sweeps the uploader's unspent SOL to Cx64. The uploader and buffer keys live in `~/.hype-project/upgrade` (mode 0600, directory 0700) and are never printed. Other commands: - `--status` shows progress; - `--dry-run` simulates the owner transaction on mainnet without sending it; - `--recover` returns the authority and refunds the buffer at any point before the upgrade. Restarting the command resumes from the bytes already on chain. See `audit/fee-upgrade-plan-20261029.md`. The public RPC is a fallback. A production RPC URL that supports browser CORS and token account queries can be configured. Do not put a secret server API key in a browser configuration. All transaction signing stays in Phantom/Solflare. ## Launches and trades Prepare public HTTPS token metadata with matching `name`, `symbol` and an `image` URL. The site checks accessibility before launch. A private website asset URL is not a valid public token metadata host. The site creates a Token-2022 pump.fun mint paired with the verified Solana HYPE mint, sets the coin's creator to its unique program PDA, configures 200 basis points, disables cashback/Mayhem/native holder-reward substitution, and registers the vault in the same signed transaction. Token trading uses the official Pump SDK before graduation and PumpSwap SDK V2 afterwards. Trades are quoted from chain, simulated, signed in the wallet and confirmed before appearing in the activity table. They include fee settlement. Other frontends may trade the same pair; anyone can subsequently call **Collect & allocate fees**. Post-graduation settlement sweeps the pool's creator-fee bucket first. External permissionless collections into the custody ATA are allocated exactly once. ## Fixed allocation and custody | Destination | Share of actual creator fees | Illustrative share of volume | |---|---:|---:| | Development, security, infrastructure & listings | 5% | 0.10% | | Long-term treasury & growth | 5% | 0.10% | | Per-token HYPE reserve | 30% | 0.60% | | Creator / holder rewards | 30% | 0.60% | | Platform-token buyback & burn | 30% | 0.60% | The first two budgets transfer into the **same treasury ATA**, totaling 10% of creator fees or 0.20% of fee-exclusive trade volume. (Owner decision 2026-10-29: treasury 30% → 10%, rewards 20% → 30%, buyback 20% → 30%; it takes effect onchain only after the program upgrade in `audit/fee-upgrade-plan-20261029.md`. Fees settled before that upgrade keep the earlier 15/15/30/20/20 allocation.) The remaining allocations stay in the token's PDA-owned HYPE custody account with separate onchain accounting. There is no administrator instruction to withdraw reserves or rewards arbitrarily. Integer rounding preserves all HYPE units. The split is applied to fees actually collected by the venue; the 2% creator fee is not an all-inclusive charge. Venue fees, rent and network fees remain separate, and all-in wallet spend can differ from the illustrative fee-exclusive volume calculator. Burn redemption uses `reserve × token units burned ÷ mint supply before burn`, rounded down. The Token-2022 burn and HYPE payment are atomic. It rejects zero-value payouts, wrong destinations and a payout below the user's minimum. This is accumulated fee backing, not a guaranteed trading price or a claim on bonding-curve liquidity. ## Rewards and buybacks Creator rewards can be triggered permissionlessly, but always pay the launcher's recorded HYPE ATA. Holder rewards require an operator-published Merkle snapshot. Generate one with: ```sh node scripts/reward-manifest.mjs --mint TOKEN_MINT \ --uri https://YOUR_PUBLIC_HOST/rewards/TOKEN-MINT-EPOCH.json ``` The script groups token accounts by wallet, excludes the curve/pool/protocol vault, optionally excludes additional disclosed owners, apportions the complete budget and generates proofs. Review and publish the exact manifest at its public URI. The configured operator can then upload that file in the token dialog and sign **Publish uploaded holder snapshot**. Recipients upload the manifest and sign **Claim holder rewards**. An epoch/recipient receipt prevents replay; wrong proofs and overspending are rejected onchain. The operator is trusted to publish a correct holder snapshot: a Merkle proof verifies the published allocation, not the accuracy of the snapshot. The client recomputes the entire Merkle root, verifies every proof and checks the allocated budget before publication. Epoch Merkle roots remain immutable. Claims expire exactly 180 days after onchain publication. After expiry, anyone can upload that epoch’s manifest and select **Return expired epoch to reward budget**. The program moves only the unclaimed amount into that same token’s unallocated reward budget; custody, treasury, reserve and buyback amounts are unchanged. Recovery cannot be repeated. Archive the exact public files and proofs for recipients. The operator selects one registered token as the permanent platform token. Once it has a canonical HYPE PumpSwap pool, **Operator buyback & burn** buys it and burns the tokens in one transaction, using only the 30% budget. This build caps execution at 0.25 HYPE per transaction and one transaction per five minutes across the protocol. The onchain minimum uses the current pool reserves; it is not a TWAP oracle. The operator must review the quote and market conditions. Buyback spending cannot consume the tracked reserve, creator rewards or allocated holder rewards. ## Dedicated unattended keeper A runnable Node service is provided in `keeper/`, with Render Blueprint and Hetzner Docker Compose/Caddy configurations. Any previously installed keeper host, delegation and funding are historical and must be re-verified before use; in this preview no keeper is live. When enabled, available budgets and pool readiness govern execution. The operator grants or revokes its separate public wallet through `automation.html`; the 80-byte canonical keeper PDA authorizes only reward-root publication and bounded platform buybacks. It cannot alter the treasury, choose the platform token, redelegate itself, upgrade the program or withdraw arbitrary reserves. A compromised keeper can publish dishonest reward Merkle roots; snapshot correctness remains a trusted server/RPC responsibility. The service rejects the operator/treasury signing key. It checks deployment and delegation before signatures, persists pending public transaction records before broadcast, verifies public immutable manifests, and enforces SOL fee/rent/day limits. Defaults are disabled and dry-run. Sponsoring holder claims requires SOL and pauses when operating caps are reached; holders can still claim themselves. One instance with persistent disk is required. See `keeper/README.md` for exact configuration, deployment and secret-handling instructions. Never publish the dedicated private key or a private Helius URL. ## Practical limits - The compiled program is tested and reviewed locally, not independently audited. The historical mainnet deployment matches the tested bytecode (read-only check, 2026-10-29) and is under re-audit. No token has been launched or traded through it. - Pump/PumpSwap and this program are upgradeable dependencies. Browser startup pins the expected deployed build; it cannot prevent later external program upgrades or protect an already-signed transaction from every future upgrade. PDA custody checks reject persistent delegate or close-authority changes in the HYPE account after buyback CPI. - Treasury and operator addresses are immutable in this program. Losing the operator wallet prevents keeper rotation/revocation and manual administrative actions; an existing funded delegate can continue its permitted tasks. Loss or compromise of the upgrade authority is a separate concern. - HYPE here is the Solana SPL mint admitted by pump.fun, not native HyperCore HYPE. Bridge provenance and conversion are external dependencies. The inspected mint has nine decimals and no freeze authority. - Totals show registered vaults and settled creator fees. There is no fabricated global trading-volume index or fabricated price feed. - Automatic periodic fee collection, holder snapshots/claim deliveries and bounded buybacks are implemented by the separate keeper service. Hosting, SOL funding, mainnet delegation and live activation are not active in this preview and must be re-verified. No live token trading or buyback is claimed while the registry is empty and the platform token is unset. Primary references: [pump.fun custom pairs](https://pump.fun/docs/custom-pairs), [official Pump SDK](https://github.com/pump-fun/pump-public-docs), [Anza SBFv3 compiler](https://github.com/anza-xyz/cargo-build-sbf). ## Capacity and platform readiness The native buyback limit is global: 0.25 HYPE every 300 seconds, at most 72 HYPE per day in theory. At a 0.60% buyback allocation, more than 12,000 HYPE of eligible daily volume can fill budgets faster than execution. Backlogs remain in each token budget. Keeper settings cannot raise this deployed cap; a tested native upgrade and owner signature are required. Use platform.html to verify the intended registered platform mint and canonical HYPE pool before approving its permanent configuration. HYPE on this site is the Solana mint 98sMhvDwXj1RQi5c5Mndm3vPe9cBqPrbLaufMXFNMh5g, listed by Pump with Sunrise/Wormhole Labs as its listing provider. No native Hyperliquid connection is implemented.