NEARFUN — COMPLETE MASTER BUILD SPECIFICATION You are the lead engineer for a production-oriented Solana application called: NearFun Act simultaneously as: * Senior Solana Protocol Engineer * Senior TypeScript Engineer * Senior Next.js Engineer * Smart Contract Integration Engineer * Security Engineer * Production Infrastructure Engineer Your task is to design, implement, test, document, and harden NearFun. Do not blindly generate code. Verify protocol assumptions first. Do not invent Pump SDK methods, program IDs, PDA derivations, token properties, fee rates, or account layouts. When this specification conflicts with the current official Pump SDK, official Pump documentation, or authoritative on-chain state, the current protocol implementation wins. Report the discrepancy before changing the implementation. ⸻ 0. PRODUCT NearFun is a non-custodial token launchpad on Solana built on top of the official Pump protocol. The defining property of NearFun is: EVERY TOKEN LAUNCHED THROUGH NEARFUN MUST TRADE AGAINST NEAR. NearFun uses Pump’s existing: * token creation infrastructure * bonding curve * trading infrastructure * creator-fee infrastructure * fee sharing * graduation process * PumpSwap integration Do NOT deploy a custom bonding curve for V1. Do NOT create a custom token-launch smart contract unless a later verified protocol limitation makes it necessary. ⸻ 1. FIXED QUOTE ASSET NearFun has exactly one quote asset: NEAR Official Pump-supported Solana mint: 3ZLekZYq2qkZiSpnSvabjit34tUkjSwD1JFuW9as9wBG Define: export const NEAR_QUOTE_MINT = new PublicKey( “3ZLekZYq2qkZiSpnSvabjit34tUkjSwD1JFuW9as9wBG” ); This is a NearFun protocol invariant. Users must NEVER be able to select: SOL USDC USDT BTC ETH or any other quote asset. Do not merely hide a quote selector. The transaction/service layer itself must enforce: quoteMint === NEAR_QUOTE_MINT Never accept quoteMint from: * user input * URL * query parameter * form * API request * local storage * database * browser state A maliciously modified frontend must not be able to make NearFun’s transaction builder produce a non-NEAR launch. ⸻ 2. CURRENT VERIFIED PRODUCT ASSUMPTION Pump’s official Supported Pair Assets documentation has independently been checked and lists: Asset: NEAR Underlying: NEAR Protocol Bridge: NEAR Omni Bridge Solana mint: 3ZLekZYq2qkZiSpnSvabjit34tUkjSwD1JFuW9as9wBG Therefore: Pump support for the NearFun quote mint is considered confirmed at the documentation/product level. However: Do NOT treat unverified mint-account properties as authoritative. The implementation must independently query the Solana mint account. ⸻ 3. RUNTIME NEAR VERIFICATION Before NearFun enables any state-changing protocol operation, verify the NEAR quote mint directly through the configured Solana Mainnet RPC. Create: src/lib/nearfun/verifyNearQuoteAsset.ts Read: 3ZLekZYq2qkZiSpnSvabjit34tUkjSwD1JFuW9as9wBG Determine: * account exists * account owner * token program * decimals * supply * mint authority * freeze authority Do not scrape explorers. Decode the actual Solana account. Do not assume: decimals = 9 even if external sources report 9. Do not assume: SPL Token Program even if external sources report it. Detect them. Return a typed result. Example conceptually: type NearQuoteAssetVerification = { mint: string; exists: boolean; tokenProgram: string; decimals: number; supply: bigint; mintAuthority: string | null; freezeAuthority: string | null; verifiedAt: Date; }; Use appropriate actual types. ⸻ 4. FAIL CLOSED If NearFun cannot verify the NEAR quote asset: disable: Launch Buy Sell Fee Distribution Allow the application to remain available in read-only/degraded mode. Display: “NEAR quote asset verification unavailable. Trading actions are temporarily disabled.” Never silently fall back to assumed decimals or token program. ⸻ 5. NON-CUSTODIAL TRUST MODEL NearFun must be non-custodial. Never request: * seed phrase * private key * secret key * wallet export * recovery phrase Never: * transmit user private keys * persist private keys * log private keys * sign ordinary user transactions server-side * create hidden transfers All user-authorized protocol actions must be approved through the connected Solana wallet. ⸻ 6. TECH STACK Use: * Next.js App Router * React * TypeScript strict mode * Tailwind CSS * Zod * wallet-standard compatible Solana wallet integration Protocol libraries: * canonical official @pump-fun/pump-sdk * canonical official PumpSwap SDK where required * @solana/web3.js * @solana/spl-token Database: PostgreSQL + Prisma only if needed. Do not make the database authoritative for blockchain state. On-chain state wins. ⸻ 7. SUPPLY-CHAIN SECURITY Before installing Pump packages: verify package provenance against Pump’s official repositories/documentation. There may be similarly named or higher-version unofficial packages. Do not select a package merely because its version number is higher. For every Pump dependency record: package name exact version official source repository reason selected Pin exact versions. Commit the lockfile. Document in: PUMP_INTEGRATION.md ⸻ 8. BRAND Project: NearFun Primary tagline: Launch on Solana. Trade in NEAR. Supporting line: Tokens launched on NearFun trade against NEAR on Solana. NearFun must have an original visual identity. Do not clone Pump.fun’s: logo branding layout CSS copyrighted graphics Design direction: * dark * modern * minimal * crypto-native * fast * mobile-first * trading-oriented ⸻ 9. ROUTES Implement: / Home /create Token creation /coin/[mint] Token details and trading /fees Creator fee dashboard /profile/[wallet] Wallet launches/activity Optional later: /search /leaderboard /admin/status ⸻ 10. HOME Header: NearFun logo/name Search Create Coin Connect Wallet Hero: NearFun Launch on Solana. Trade in NEAR. CTA: Launch a Coin Sections: Recent launches Trending tokens if reliable data exists How NearFun works Fee disclosure NEAR quote explanation Never fabricate: volume market cap price trade counts holders ⸻ 11. WALLET Support maintained Solana wallet-standard compatible wallets. Show: wallet public key SOL balance NEAR balance Example: SOL 0.132 Network fees NEAR 24.82 Trading asset Make the distinction explicit: SOL pays Solana network fees. NEAR is NearFun’s trading/quote asset. Connecting a wallet must NEVER initiate a transaction. ⸻ 12. SOL REQUIREMENT Users still require SOL for: network fees account creation/rent where applicable Before a write transaction check available SOL. If insufficient: “You need a small amount of SOL for Solana network fees.” Never imply NEAR pays Solana gas. ⸻ 13. NEAR BALANCE After verifying the NEAR mint: determine the actual token program. Find the connected wallet’s appropriate token accounts. Do not assume an ATA exists. If no NEAR token account exists: show: 0 NEAR not an error. Correctly aggregate balance if multiple relevant token accounts must be considered. ⸻ 14. AMOUNT SYSTEM All raw financial quantities must use: bigint Never use JavaScript floating point for raw token values. Centralize: parseTokenAmount() formatTokenAmount() toRawAmount() fromRawAmount() Decimals must come from authoritative mint/protocol data. Never spread: * 1e9 or: / 1e6 throughout the codebase. ⸻ 15. CREATE PAGE Route: /create Fields: Token Image Token Name Symbol Description Optional: Website X/Twitter Telegram No quote selector. Display: Quote Asset NEAR Trading Pair SYMBOL / NEAR Example: DOG / NEAR ⸻ 16. TOKEN METADATA Implement a storage abstraction: interface MetadataStorageProvider { upload(input): Promise<{ uri: string; }>; } Support one working provider. Do not tightly couple NearFun to one vendor. Validate: MIME type file size name symbol description links Sanitize input. Never expose private storage credentials in browser JavaScript. ⸻ 17. TOKEN CREATION Use Pump’s current official token creation interface. Expected modern flow: create_v2 But: inspect the current official SDK first. Use the exact installed SDK method/signature. Never invent it. NearFun must internally inject: quoteMint = NEAR_QUOTE_MINT Do not accept it as a parameter from React components. Architecture conceptually: createNearFunCoin({ creator, metadata, … }) NOT: createCoin({ quoteMint: arbitraryUserInput }) The NearFun service chooses NEAR. ⸻ 18. BASE TOKEN STANDARD Respect the current Pump implementation. If Pump currently creates base tokens through Token-2022: use the official flow. Do not manually replace Pump’s mint creation. Do not assume: base token program === quote token program Treat them separately. ⸻ 19. OPTIONAL INITIAL BUY Allow creator to optionally purchase tokens during launch. UI: Initial Buy 0 NEAR 1 NEAR 5 NEAR Custom Optional means optional. If current Pump SDK supports safe composition: use official implementation. Otherwise use separate wallet-approved transactions. Never pretend unsupported operations are atomic. ⸻ 20. LAUNCH REVIEW Before requesting signatures show: Token Name: Example Coin Symbol: EXAMPLE Pair: EXAMPLE / NEAR Quote Asset: NEAR Initial Buy: 5 NEAR Creator Fee Distribution: Creator 80% NearFun 20% Network: Solana Mainnet Then: Launch Coin No wallet signature request before the user reviews the configuration. ⸻ 21. CREATOR FEE SHARING NearFun should configure Pump Creator Fee Sharing for NearFun-launched coins. Business configuration: NearFun receives a configurable percentage of the Pump creator-fee allocation. Creator receives the remainder. Environment: NEXT_PUBLIC_NEARFUN_PLATFORM_SHARE_BPS= Example: 2000 means: NearFun receives 20% of the Pump creator-fee allocation. Creator receives 80%. It does NOT mean: 20% of trading volume and does NOT mean: 20% of all Pump protocol fees. ⸻ 22. PLATFORM WALLET Environment: NEXT_PUBLIC_NEARFUN_PLATFORM_WALLET= This must be a PUBLIC Solana address. NearFun does not require its private key merely to receive its creator-fee share. Never put a platform private key in frontend code. Validate the address at startup. ⸻ 23. FEE SPLIT VALIDATION Validate: 0 <= platformShareBps <= 10000 creatorShareBps = 10000 - platformShareBps Total: 10000 bps Potential shareholders: creator wallet NearFun platform wallet Handle: platform share = 0 creator share = 0 creator wallet == platform wallet duplicate addresses unsupported zero-share recipients current Pump shareholder count limit Never create invalid duplicate shareholders. ⸻ 24. FEE SHARING FLOW Use the current official Pump fee-sharing lifecycle. Expected concepts include: createFeeSharingConfig updateFeeSharesV2 but verify exact SDK methods/signatures. Never invent method names. Conceptually: create sharing configuration then: finalize shareholder allocation Expected logical allocation: [ { address: creator, shareBps: creatorShareBps }, { address: NEARFUN_PLATFORM_WALLET, shareBps: platformShareBps } ] Total must equal: 10000 ⸻ 25. FEE SPLIT IMMUTABILITY Current Pump behavior may make finalized sharing configuration effectively immutable/admin-revoked. Verify current behavior. Before finalization show: “Final creator-fee allocation” Warn: “Once finalized on-chain, these fee-sharing recipients and percentages cannot be edited through NearFun.” Require explicit confirmation. Do not implement a fake post-launch fee-editing UI if the protocol does not permit it. ⸻ 26. FEE DISCLOSURE Clearly distinguish: Pump protocol fee Pump creator fee NearFun’s share of creator fee Solana network fees Potential future interface fee Never misrepresent platform economics. ⸻ 27. BUY FLOW Use Pump’s current official buy interface. Expected: buy_v2 Verify exact SDK implementation. Trading flow: NEAR → Pump bonding curve → TOKEN Before wallet approval show: You Pay X NEAR You Receive ~Y TOKEN Slippage Maximum spent / minimum received as appropriate Fees where reliably known Network fee estimate where available Require explicit Buy action. ⸻ 28. SELL FLOW Use Pump’s current official sell interface. Expected: sell_v2 Verify exact SDK implementation. Flow: TOKEN → Pump bonding curve → NEAR Before wallet approval show: You Sell X TOKEN You Receive ~Y NEAR Slippage Minimum received Fees Require explicit Sell action. ⸻ 29. SLIPPAGE Provide: 0.5% 1% 2% Custom Use basis points/integer arithmetic. Validate custom input. Never hide slippage. ⸻ 30. TRADING SAFETY Before trading: verify current bonding curve state verify graduation status verify quote mint verify balances verify token programs obtain fresh blockhash build transaction simulate where practical request wallet approval submit confirm read resulting state Only then display success. ⸻ 31. GRADUATION Detect graduation using authoritative Pump state. Do not use database status as the source of truth. Once bonding curve completes: detect PumpSwap pool/state. Stop routing trades through bonding curve. Use current official PumpSwap flow. Continue displaying: TOKEN / NEAR ⸻ 32. PUMPSWAP Inspect current PumpSwap SDK/documentation. Determine exact flow for: TOKEN / NEAR after graduation. Verify: pool accounts token programs quote mint pricing swap methods fee handling Never assume PumpSwap only supports SOL pairs. Do not implement guessed pool layouts. ⸻ 33. NON-NATIVE QUOTE FEE DISTRIBUTION NEAR is a token quote asset rather than native SOL. Creator fee distribution must correctly handle token accounts. For every shareholder: derive/use the correct NEAR token account according to the actual token program. Use official SDK handling where available. Do not manually guess remaining-account order. If ATA initialization is required: use the current SDK-supported mechanism. The caller may need SOL for account creation. Explain this in UI. ⸻ 34. FEE DASHBOARD Route: /fees Show coins relevant to connected wallet. For each: Token TOKEN / NEAR Creator share NearFun share Bonding curve/graduation state Accumulated creator fees if reliably obtainable Distribution state Action: Distribute Fees Do not display fabricated accrued amounts. ⸻ 35. PRE-GRADUATION FEE DISTRIBUTION Use Pump’s official creator-fee distribution flow. Verify exact SDK method. Read sharing config from chain. Verify recipients. Verify shares. Build official distribution transaction. Request wallet approval where required. Confirm. Read state again. ⸻ 36. POST-GRADUATION FEE DISTRIBUTION For graduated coins determine whether PumpSwap creator fees must first be transferred/swept into Pump’s creator-fee distribution mechanism. Expected conceptual methods may include: transferCreatorFeesToPumpV2 distributeCreatorFeesV2 Verify exact current methods. Do not assume names. Correct sequence must come from current official SDK/docs. ⸻ 37. LAUNCH STATE MACHINE Do not use one loading boolean. Implement: IDLE VALIDATING UPLOADING_METADATA METADATA_READY AWAITING_CREATE_SIGNATURE SUBMITTING_CREATE CONFIRMING_CREATE CREATE_CONFIRMED AWAITING_INITIAL_BUY_SIGNATURE SUBMITTING_INITIAL_BUY CONFIRMING_INITIAL_BUY INITIAL_BUY_CONFIRMED AWAITING_SHARING_CONFIG_SIGNATURE SUBMITTING_SHARING_CONFIG CONFIRMING_SHARING_CONFIG SHARING_CONFIG_CONFIRMED AWAITING_FINAL_SHARES_SIGNATURE SUBMITTING_FINAL_SHARES CONFIRMING_FINAL_SHARES COMPLETE PARTIAL_FAILURE FAILED Skip initial-buy states when no initial buy is requested. ⸻ 38. PARTIAL FAILURE Critical: Token creation may succeed while: initial buy or: fee-sharing setup fails. Never lose the successful mint. Example UI: Coin created ✓ Initial buy ✓ Fee-sharing configuration ✕ Message: “Your token was created successfully, but NearFun fee-sharing setup is incomplete.” Action: Resume Setup ⸻ 39. RESUME SETUP Before resuming: read current on-chain state. Determine: coin exists? initial buy already executed? sharing config exists? shares finalized? Never blindly replay every transaction. Never submit an instruction twice merely because local state was lost. Make recovery idempotent where possible. ⸻ 40. TRANSACTION PIPELINE Centralize transaction behavior. Suggested structure: src/lib/solana/ connection.ts tokens.ts amounts.ts balances.ts src/lib/nearfun/ constants.ts config.ts verifyNearQuoteAsset.ts launchState.ts launchService.ts src/lib/pump/ sdk.ts create.ts buy.ts sell.ts feeSharing.ts fees.ts graduation.ts pumpSwap.ts src/lib/transactions/ build.ts simulate.ts send.ts confirm.ts errors.ts Do not build Pump transactions directly inside React components. ⸻ 41. TRANSACTION RULE For state-changing operations: 1. Validate configuration. 2. Fetch fresh chain state. 3. Verify NEAR quote invariant. 4. Verify relevant token programs. 5. Build official instructions. 6. Obtain recent blockhash. 7. Simulate where appropriate. 8. Request wallet signature. 9. Submit. 10. Confirm. 11. Read post-transaction state. 12. Verify expected state transition. A transaction signature alone is not sufficient proof of application success. ⸻ 42. ERROR HANDLING Create human-readable errors for: Wallet rejected transaction Insufficient SOL Insufficient NEAR Insufficient base token RPC unavailable RPC timeout Blockhash expired Simulation failed Pump program error Slippage exceeded Missing token account Unexpected token program Invalid NEAR mint state Unsupported network Bonding curve completed Coin graduated Sharing config already exists Fee shares already finalized Metadata upload failed Transaction confirmation timeout Preserve underlying technical errors for debugging. ⸻ 43. TOKEN PAGE Route: /coin/[mint] Display: Image Name Symbol Pair: TOKEN / NEAR Mint Creator Quote: NEAR Bonding curve progress Price in NEAR Market cap in NEAR if reliably calculated Graduation state Fee-sharing configuration Buy Sell Explorer links Recent activity if reliable index data exists Never fabricate market data. ⸻ 44. PRICE Primary denomination: NEAR Example: 1 TOKEN = 0.000042 NEAR Optional fiat conversion may be added later. USD must not be required for MVP. ⸻ 45. INDEXING Do not build feeds by performing thousands of browser RPC calls. Create: interface NearFunIndexProvider { getRecentLaunches(); getCoin(mint); getTrades(mint); getCoinsByCreator(wallet); } Indexer/backend is a read optimization. Chain remains authoritative. ⸻ 46. IDENTIFYING NEARFUN LAUNCHES NearFun must distinguish NearFun launches from arbitrary Pump tokens. Persist/index: mint creator creation signature creation timestamp quote mint sharing config NearFun shareholder launch status Verify: quoteMint === NEAR_QUOTE_MINT Do not identify NearFun coins only by: name symbol metadata ⸻ 47. DATABASE If persistence is required use PostgreSQL + Prisma. Possible Launch model: id mint creator quoteMint creationSignature sharingConfig status createdAt Never store: seed phrase private key secret wallet material Do not store balances as authoritative protocol truth. ⸻ 48. RPC ARCHITECTURE Create centralized RPC configuration. Environment: NEXT_PUBLIC_SOLANA_NETWORK= NEXT_PUBLIC_SOLANA_RPC_URL= Production NearFun must use: mainnet-beta Be careful with credential-bearing public RPC URLs. Design so sensitive RPC access can later be proxied server-side. Never print private RPC credentials in UI or logs. ⸻ 49. ENVIRONMENT Create: .env.example Include: NEXT_PUBLIC_SOLANA_NETWORK=mainnet-beta NEXT_PUBLIC_SOLANA_RPC_URL= NEXT_PUBLIC_NEARFUN_PLATFORM_WALLET= NEXT_PUBLIC_NEARFUN_PLATFORM_SHARE_BPS= DATABASE_URL= metadata provider variables Never commit real secrets. ⸻ 50. PROTOCOL STATUS Create an internal development status view. Display: Network RPC reachable NEAR quote mint NEAR verification status Detected token program Detected decimals Mint authority Freeze authority Last verification time Pump SDK version Pump program ID PumpSwap SDK version PumpSwap program ID Never expose sensitive RPC credentials. ⸻ 51. LOGGING Use structured logs. Allowed: public wallet addresses mint transaction signature transaction type network confirmation result error code Never log: private keys seed phrases auth secrets sensitive provider credentials ⸻ 52. SECURITY THREAT MODEL Document and protect against: malicious frontend input quote-mint substitution transaction tampering stale RPC state duplicate transaction submission fake launch completion unsafe package substitution metadata injection XSS secret leakage network mismatch malicious/compromised RPC responses where practical wallet-signature confusion hidden transfers fee-recipient substitution ⸻ 53. USER TRANSACTION TRANSPARENCY Before signatures make the purpose clear. For creation: Creating TOKEN / NEAR For buy: Spending X NEAR to buy TOKEN For sell: Selling X TOKEN for NEAR For fee sharing: Setting Creator X% NearFun Y% For fee distribution: Distributing accumulated Pump creator fees according to the on-chain sharing configuration Never obscure what the wallet is being asked to sign. ⸻ 54. TESTS Unit tests: environment validation NearFun platform wallet validation BPS validation NEAR quote invariant amount parsing amount formatting bigint arithmetic duplicate shareholders same creator/platform wallet zero platform share launch state transitions partial failure recovery slippage math unsupported token program RPC verification failure missing NEAR token account Integration tests: create transaction builder initial buy builder buy builder sell builder fee-sharing builder fee distribution graduation detection PumpSwap routing Mock: wallet rejection RPC timeout blockhash expiration simulation failure partial launch completion Never perform uncontrolled Mainnet transactions in automated tests. ⸻ 55. DOCUMENTATION Maintain: README.md ARCHITECTURE.md SECURITY.md PUMP_INTEGRATION.md NEAR_QUOTE_ASSET.md FEE_MODEL.md TRANSACTION_FLOWS.md ⸻ 56. NEAR_QUOTE_ASSET.md Clearly separate: OFFICIALLY CONFIRMED Pump lists: 3ZLekZYq2qkZiSpnSvabjit34tUkjSwD1JFuW9as9wBG as a supported NEAR quote asset. RUNTIME VERIFIED Values read directly from Solana RPC: token program decimals supply mint authority freeze authority Do not report runtime values as verified until actually queried. ⸻ 57. PUMP_INTEGRATION.md Record: exact SDK package exact version package provenance repository program IDs relevant instructions PDAs create flow buy flow sell flow fee sharing graduation PumpSwap fee distribution Any docs/SDK discrepancy must be recorded. ⸻ 58. FEE_MODEL.md Explain: Pump protocol fee Pump creator fee NearFun creator-fee share network fees fee distribution non-native quote behavior Do not use misleading revenue terminology. ⸻ 59. ARCHITECTURE.md Explain: Frontend Wallet boundary RPC Backend Database Indexer Metadata storage Pump PumpSwap Transaction builders Verification layer Failure recovery ⸻ 60. SECURITY.md Document: non-custodial model secret handling wallet boundaries transaction verification package provenance RPC assumptions quote-mint invariant fee recipient validation threat model ⸻ 61. DEVELOPMENT PHASES Do not build everything blindly. Execute sequentially. PHASE 1 — PROTOCOL VERIFICATION Already substantially completed. Status: CONDITIONAL PASS Confirmed: Pump officially supports NearFun’s NEAR mint. Still runtime-verify mint properties through real Mainnet RPC. Do not fake verification if environment lacks outbound connectivity. ⸻ PHASE 2 — FOUNDATION Build: Next.js TypeScript strict Tailwind wallet integration config environment validation RPC layer NEAR runtime verification SOL balance NEAR balance routes UI foundation tests Do NOT implement Pump write transactions yet. At end: build lint typecheck tests Then report. ⸻ PHASE 3 — PUMP READ LAYER Implement: Pump SDK initialization global state reads bonding curve reads coin state quote verification graduation detection fee-sharing reads No production write flow yet. Verify all PDAs/methods against current SDK. ⸻ PHASE 4 — TOKEN CREATION Implement: metadata upload create_v2 fixed NEAR quote wallet signing simulation confirmation post-state verification optional initial buy only after base creation works reliably ⸻ PHASE 5 — FEE SHARING Implement: sharing config final shareholder allocation NearFun platform share read-back verification immutability warning partial failure recovery ⸻ PHASE 6 — BUY / SELL Implement: NEAR → TOKEN TOKEN → NEAR slippage balances quotes simulation confirmation post-state verification ⸻ PHASE 7 — TOKEN PAGE Implement: real on-chain token state bonding curve NEAR price buy/sell panel fee-sharing display graduation ⸻ PHASE 8 — PUMPSWAP Implement: graduated pool discovery TOKEN/NEAR swaps correct token programs post-graduation routing ⸻ PHASE 9 — CREATOR FEES Implement: pre-graduation distribution post-graduation fee transfer/sweep non-native NEAR token accounts distribution verification ⸻ PHASE 10 — INDEXER Implement: recent launches wallet launches trades activity profiles Do not replace chain authority with indexer state. ⸻ PHASE 11 — HARDENING Security review error recovery mobile performance accessibility RPC resilience transaction idempotency package audit tests ⸻ PHASE 12 — MAINNET RELEASE REVIEW Before production writes: perform manual Mainnet readiness review. Verify: NEAR mint Pump programs Pump SDK PumpSwap platform wallet platform share RPC metadata storage database monitoring fee disclosures transaction previews Do not automatically perform financial Mainnet transactions merely because tests pass. Require explicit controlled release procedure. ⸻ 62. PHASE GATES At the end of every phase: run: npm run build npm run lint npm run typecheck npm test Fix errors before proceeding. Return a review report containing: work completed files changed dependencies added tests build result lint result typecheck result security findings unresolved issues protocol assumptions Do not conceal failures. ⸻ 63. CODING QUALITY Use: strict TypeScript typed service interfaces small focused modules explicit errors Zod validation bigint testable transaction builders Avoid: any unsafe type casts giant React components business logic in JSX duplicated RPC code hard-coded decimals hard-coded financial assumptions magic addresses spread through code ⸻ 64. NO FAKE DATA Never make a production page look functional using fabricated blockchain data. Development placeholders must be explicitly identified. If data is unavailable: show unavailable/loading/error. Do not invent: price market cap volume fees transactions holders balances ⸻ 65. MAINNET SAFETY Do not send a Mainnet transaction merely to test whether code works. Use: read-only Mainnet verification unit tests mocks simulation supported development environments controlled manual testing When actual Mainnet writes become necessary, stop and provide: exact transaction purpose expected asset movement expected fees wallet required risk verification steps before proceeding. ⸻ 66. NEARFUN CORE INVARIANTS These must always remain true: INVARIANT 1 NearFun quote asset is always: 3ZLekZYq2qkZiSpnSvabjit34tUkjSwD1JFuW9as9wBG INVARIANT 2 NearFun does not custody user private keys. INVARIANT 3 Raw financial values use bigint. INVARIANT 4 On-chain state is authoritative. INVARIANT 5 Fee allocations are disclosed before signature. INVARIANT 6 NearFun never claims creator-fee share is a percentage of total trading volume. INVARIANT 7 Transactions are not considered successful until confirmed and expected state is verified. INVARIANT 8 Graduated coins do not continue using the bonding-curve trade path. INVARIANT 9 Runtime token properties are read from authoritative state rather than guessed. INVARIANT 10 A failed fee-sharing step must not cause a successfully created token to be lost from NearFun recovery state. ⸻ 67. DEFINITION OF MVP DONE NearFun MVP is complete when: 1. User can connect a Solana wallet. 2. SOL balance displays. 3. NEAR balance displays. 4. NEAR quote mint is runtime-verified. 5. User can submit token metadata. 6. NearFun creates the token through official Pump infrastructure. 7. Quote mint is guaranteed to be: 3ZLekZYq2qkZiSpnSvabjit34tUkjSwD1JFuW9as9wBG 8. Optional initial purchase works using NEAR. 9. Creator fee sharing is configured. 10. NearFun receives its configured share of Pump creator fees. 11. Sharing configuration can be independently read back from chain. 12. Token can be bought with NEAR. 13. Token can be sold for NEAR. 14. Slippage is correctly enforced. 15. Bonding curve state displays. 16. Graduation is detected. 17. Graduated TOKEN/NEAR trading correctly moves to PumpSwap. 18. Creator fees can be distributed correctly for the NEAR quote asset. 19. Partial launches can be resumed safely. 20. No user private key touches NearFun. 21. No quote token other than NEAR can be used by NearFun’s launch builder. 22. Fee allocation is disclosed before signing. 23. No fabricated market data is displayed. 24. Tests pass. 25. TypeScript passes. 26. Lint passes. 27. Production build passes. 28. Documentation is complete. ⸻ 68. RULE OF AUTHORITY The order of authority is: 1. Authoritative current on-chain state 2. Current official Pump SDK implementation 3. Current official Pump documentation 4. Current official Solana documentation 5. NearFun specification If they conflict: do not force the code to match this prompt. Stop. Identify the discrepancy. Explain its impact. Update the implementation based on the authoritative source. Never invent unsupported behavior. ⸻ 69. CURRENT STARTING POINT Phase 1 has produced: CONDITIONAL PASS. Pump’s official Supported Pair Assets documentation independently confirms NEAR support for: 3ZLekZYq2qkZiSpnSvabjit34tUkjSwD1JFuW9as9wBG Direct Mainnet RPC verification of the mint account was not completed in the previous sandbox because outbound network access was unavailable. Therefore: DO NOT redo Phase 1 from scratch unless current evidence has changed. Proceed to Phase 2. The first real RPC-capable environment must verify: account owner token program decimals supply mint authority freeze authority before enabling NearFun state-changing actions. ⸻ 70. YOUR NEXT TASK Start PHASE 2 now. Do not ask me generic implementation questions that can be safely resolved from this specification or current authoritative documentation. Do not implement Pump write transactions during Phase 2. Build the project foundation. At the end of Phase 2: run all required checks and return: NEARFUN PHASE 2 REVIEW REPORT Include: 1. Project structure 2. Exact dependencies and versions 3. Pump package provenance findings 4. Wallet integration 5. Environment configuration 6. RPC architecture 7. Actual NEAR mint RPC verification result if network access is available 8. Detected token program 9. Detected decimals 10. Supply 11. Mint authority 12. Freeze authority 13. SOL balance implementation 14. NEAR balance implementation 15. Fail-closed behavior 16. Tests executed 17. Test results 18. Build result 19. Typecheck result 20. Lint result 21. Security findings 22. Unresolved issues 23. Files created/changed 24. Exact recommended next steps for Phase 3 If Mainnet RPC access is unavailable: state: “MAINNET RPC VERIFICATION NOT EXECUTED” Do not substitute explorer scraping. Do not fabricate results. Then STOP. Wait for review before beginning Phase 3.