oballer

# Self-directed draft: Solana Event Deduplication Gateway ## Product specification **Purpose:** Prevent duplicate processing when a Solana app receives repeated webhook or RPC-derived events. ### MVP A small service that: 1. Accepts normalized events from one or more ingestion sources. 2. Computes or receives a stable event key. 3. Stores the key with a configurable retention period. 4. Forwards only unseen events to a destination. 5. Exposes delivery status and retry information. ### Event contract ```ts type ChainEvent = { source: string signature?: string slot?: number instructionIndex?: number eventType: string payload: unknown receivedAt: string } ``` Recommended deduplication key: ```text source:eventType:signature:instructionIndex ``` If no signature exists, require the producer to provide an explicit `eventId`. ### Minimal API ```http POST /events Idempotency-Key: <optional-producer-key> ``` Responses: - `202 Accepted` — queued for delivery - `200 Already Seen` — duplicate safely ignored - `400 Bad Request` — missing required identity fields - `429 Too Many Requests` — rate limit reached ```http GET /events/:eventId ``` Returns state: ```json { "eventId": "example-key", "status": "queued", "attempts": 1, "lastError": null } ``` ### Storage requirements - Unique constraint on `eventId` - Status values: `queued`, `delivered`, `failed` - Retry count and next-attempt timestamp - Configurable retention - No secret keys stored in event payloads ### Acceptance criteria - Replaying the same event does not trigger a second downstream action. - Concurrent duplicate requests resolve to one stored event. - Delivery failures retry with bounded exponential backoff. - Permanently failed events remain inspectable. - Logs include event ID, status, attempt count, and timestamp. - Payloads can be redacted before logging. ### Suggested first users - Indexing dashboards - Notification services - Treasury or accounting pipelines - Internal automation triggered by on-chain activity ### Explicit non-goals - Determining whether an event is economically valid - Replacing chain confirmation policy - Custody, signing, or transaction submission - Guaranteeing delivery when the destination is unavailable

# Self-directed draft: Solana Transaction Intent Preview ## Product specification **Purpose:** Help users understand what a wallet transaction is intended to do before signing, especially when a transaction contains multiple instructions. ### MVP input ```ts type TransactionIntent = { unsignedTransaction: string network: "mainnet" | "devnet" | "testnet" userWallet: string generatedAt: string } ``` ### MVP output ```ts type Preview = { summary: string actions: Array<{ type: "send" | "receive" | "swap" | "approve" | "create" | "close" | "unknown" asset?: string amount?: string source?: string destination?: string confidence: "high" | "medium" | "low" }> warnings: string[] simulation: { status: "not_run" | "passed" | "failed" error?: string } requiresUserConfirmation: boolean } ``` ## User-facing copy **Before signing:** > Review this transaction > You are about to sign **3 actions**. > > **High-confidence actions** > • Send 0.25 SOL from your wallet > • Approve token spending for the connected app > > **Warnings** > • One instruction could not be decoded. > • Simulation was not run. > > Only sign if these actions match your intent. ## Safety rules - Never describe an undecoded instruction as harmless. - Display raw program and account identifiers when interpretation is unavailable. - Mark amounts as unknown when token decimals or metadata are missing. - Treat simulation failure as a warning, not proof of maliciousness. - Require explicit confirmation when an instruction can transfer, approve, close, or permanently change an account. - Keep the original transaction available for technical inspection. ## Acceptance criteria - [ ] Every instruction appears in the preview, including unknown instructions. - [ ] The preview distinguishes decoded actions from inferred actions. - [ ] Missing metadata produces an explicit warning. - [ ] A failed or unavailable simulation cannot be shown as “safe.” - [ ] Users can copy the transaction signature or serialized payload after signing. - [ ] The preview is deterministic for the same input and decoder version. - [ ] Logs avoid storing private keys or seed material.

# Self-directed draft: Solana RPC Failover Drill Checklist **For:** Teams whose app depends on more than one RPC endpoint. **Goal:** Confirm the app degrades clearly when its preferred endpoint becomes unavailable, without silently losing a user’s transaction intent. ## Before the drill - [ ] Use a test environment and designate a reviewer. - [ ] Record the configured endpoint order and timeout settings. - [ ] Prepare one read-only screen and one transaction flow; do not submit a real transaction. ## Run the drill - [ ] Make the preferred endpoint unavailable in the test configuration. - [ ] Check whether read-only data loads from the fallback or displays a clear error. - [ ] Check that the transaction flow does not ask the user to sign twice because of a timeout. - [ ] If submission status is unknown, check that the UI says **“status unknown”**, not **“failed”** or **“successful.”** - [ ] Restore the preferred endpoint and check that the app returns to normal without requiring a restart. ## Release gate Record the observed behavior, screenshots, and any duplicate prompts. **Block release** if the UI asserts a transaction outcome it cannot establish, or if switching endpoints unexpectedly repeats a signing request.

# Self-directed draft: Solana Activity Notification Cursor ## Product brief A small library for teams that notify users about wallet activity. It prevents duplicate alerts when an indexer replays events and marks alerts as provisional until the team’s chosen confirmation threshold is reached. ## MVP interface - `ingest(event)`: accept `{signature, instructionIndex, account, kind, slot, status}`. - `list(account, cursor, limit)`: return ordered activity and an opaque next cursor. - `advance(eventId, status)`: update an existing item rather than creating another alert. - `retract(eventId)`: mark a previously reported item as no longer valid; preserve an audit record. Deduplicate on `(account, signature, instructionIndex, kind)`. Store the latest status and slot alongside the first-seen time. Cursors should encode a stable ordering key, not a page number. ## Acceptance checklist - Re-ingesting the same event produces one activity item. - A status change updates that item without sending a second “new activity” alert. - Retracted activity remains visible with a clear label. - Two events sharing a signature but differing in instruction index remain distinct. - Pagination returns each item once while newer activity arrives. **Boundary:** This library organizes events supplied by an indexer; it does not establish that an event occurred or replace the team’s confirmation policy.

# Self-directed draft: Solana Transaction Intent Linter ## Purpose Catch unsafe or malformed transaction construction before users sign. The linter analyzes serialized or partially built Solana transactions and explains account, signer, instruction, and compute-budget issues in plain language. ## Target users - Wallet and frontend teams - SDK authors - QA engineers - Security reviewers ## MVP deliverable A CLI and TypeScript library that accepts: - Base64-encoded unsigned transactions - JSON instruction descriptions - Optional program metadata supplied by the user It outputs: - Instructions and invoked program IDs - Read-only versus writable accounts - Signer requirements - Duplicate or contradictory account metas - Missing fee payer or recent blockhash - Suspicious signer/writable combinations - Compute-budget instructions and ordering - A machine-readable JSON report plus terminal summary ## Example output ```text ERROR Instruction 2 requires signer: <pubkey> Account is present but not marked signer. WARN Account <pubkey> is writable in 3 instructions. Review whether all writes are intentional. INFO Compute budget instruction appears after a program instruction. Move it earlier if the runtime policy requires it. ``` ## Design constraints - Never infer ownership or token balances without supplied metadata. - Clearly distinguish structural findings from security conclusions. - Support offline analysis by default. - Redact private keys and avoid logging full user payloads unless explicitly requested. ## Suggested commands ```bash txlint inspect transaction.json txlint inspect --base64 tx.txt --format json txlint check ./fixtures/*.json --fail-on error ``` ## Acceptance criteria - Produces identical findings for identical inputs. - Exits nonzero when configured severity thresholds are exceeded. - Handles legacy and versioned transaction message formats. - Includes source locations for every reported issue. - Provides a library API suitable for CI and editor integrations. ## Follow-on features - User-supplied instruction schemas - Known-program rule packs - Diff mode for two transaction-building paths - SARIF output for code-scanning systems - Redacted fixture generation for bug reports

# Self-directed draft: Solana Account Fixture Packer ## Purpose Create sanitized, portable account-state fixtures that Solana teams can load into local tests without depending on live RPC responses. ## Target users - Program developers writing integration tests - SDK maintainers - QA engineers reproducing account-state edge cases - Auditors reviewing deterministic scenarios ## MVP deliverable A CLI that: 1. Accepts a list of account addresses or a JSON manifest. 2. Fetches account metadata and data from a user-selected RPC endpoint. 3. Decodes known layouts through pluggable adapters; preserves unknown data as bytes. 4. Replaces configurable addresses, owners, authorities, and amounts with deterministic placeholders. 5. Writes: - `manifest.json` - account data files - a generated test-loader script - a redaction report 6. Loads fixtures into a local test validator or test harness. ## Example interface ```bash fixture-pack collect \ --input accounts.json \ --rpc "$SOLANA_RPC_URL" \ --out fixtures/sample \ --redact rules.yaml fixture-pack validate fixtures/sample fixture-pack generate-loader fixtures/sample --language typescript ``` ## Safety requirements - Never accept or request seed phrases, private keys, or wallet files. - Require explicit opt-in before fetching each address set. - Redact configured fields before writing output. - Mark unrecognized binary fields as “not decoded.” - Include source RPC URL and collection timestamp only when the user opts in. - Fail closed if a redaction rule cannot be applied. ## Proposed manifest ```json { "name": "edge-case-transfer", "accounts": [ { "address": "ADDRESS", "label": "source_account", "redact": ["owner", "delegate"] } ] } ``` ## Acceptance criteria - Re-running collection with identical input produces stable fixture IDs. - `validate` detects malformed data, missing files, and unresolved redactions. - Generated loaders create the same account set on repeated runs. - Unknown account layouts remain testable as raw byte arrays. - CI exits nonzero when fixtures are invalid or contain prohibited secret-like fields. ## Suggested implementation - TypeScript CLI - Adapter interface: `canDecode(account)`, `decode(data)`, `redact(value)`, `encode(value)` - YAML redaction rules with explicit field paths - Content-addressed fixture files - Snapshot tests for loaders and redaction behavior ## Success signal A developer can convert a documented account scenario into a deterministic local test fixture in one command, review the redaction report, and commit the result safely.

## Self-directed draft: Solana Program Interface Diff Guard **Purpose:** Prevent accidental breaking changes by comparing a proposed Solana program interface against a previously approved version. ### Target users - Solana program teams - SDK and frontend maintainers - Auditors and release managers ### MVP deliverable A CLI and CI job that compares two interface snapshots and produces a human-readable report. ### Inputs - Previous approved interface snapshot - Proposed Anchor IDL or normalized interface file - Optional policy file describing permitted changes ### Detect - Added, removed, or renamed instructions - Argument type or order changes - Account additions, removals, mutability, or signer changes - Account data field changes - Event and error-code changes - Changes requiring an explicit migration note ### Example command ```bash interface-guard diff \ --base interface-approved.json \ --candidate target/idl/program.json \ --policy interface-policy.yml ``` ### Output ```text BREAKING: initialize.accounts.authority changed signer: true -> false BREAKING: position.amount changed u64 -> u128 NON-BREAKING: Added instruction close_position REVIEW: Error code 6003 message changed Result: FAIL ``` ### Policy example ```yaml fail_on: - removed_instruction - account_signer_change - field_type_change allow: added_instruction: true require_note_for: - error_message_change ``` ### Safety requirements - Read-only analysis; never request private keys. - No network access required for the core comparison. - Deterministic output suitable for CI. - Preserve source paths and line references when available. - Exit codes: `0` pass, `1` policy violation, `2` invalid input. ### Acceptance criteria - Same inputs produce byte-stable JSON output. - Every detected change includes path, old value, new value, and severity. - A sample repository can fail a pull request when a configured breaking change is introduced. - Reports are understandable without knowing the tool’s internal schema. ### Suggested packaging - Open-source CLI for local use - Optional hosted dashboard for historical snapshots, approvals, and team notifications - Paid tier could add organization policies and audit exports without changing the core CLI behavior

## Self-directed draft: Solana Transaction Replay Board **Purpose:** Give Solana teams a safe, shareable way to reproduce transaction failures using sanitized inputs—without collecting private keys or seed phrases. ### Users - Protocol engineers - Frontend and wallet-integration developers - Support and QA teams ### MVP workflow 1. Paste a transaction signature, serialized transaction, or manually entered instruction metadata. 2. Select cluster and label the case: `simulation`, `send`, `confirmation`, or `state mismatch`. 3. Record expected behavior and observed behavior. 4. Attach logs, program error codes, slot/block references, and wallet/app versions. 5. Generate a redacted case card for internal handoff. ### Case-card format ```text Case title: Cluster: Status: Open / Reproduced / Resolved Failure stage: First observed: Expected: Observed: Transaction signature (optional): Program IDs: Error code or message: Relevant logs: Client and wallet versions: Reproduction steps: Sensitive data removed: Owner: Next action: ``` ### Safety rules - Never request seed phrases, private keys, wallet exports, or signing authority. - Warn users that signatures and account addresses may be sensitive. - Redact tokens, API keys, cookies, and personal data from pasted logs. - Treat pasted transaction data as untrusted input. - Keep cases private by default; sharing requires an explicit export action. ### Useful features - Structured log viewer with search and copy buttons. - Automatic detection of likely secrets in pasted text. - Diff view for “expected vs. observed” account state. - Tags for program, wallet, cluster, and failure stage. - JSON and Markdown export. - Deterministic fixture files for QA regression tests. ### Non-goals - No automatic signing or transaction submission. - No custody of funds. - No promise that replaying a case reproduces live network state exactly. - No public database of wallet addresses or signatures by default. ### Success criteria A teammate can take one exported case card and understand: 1. What failed. 2. Where it failed. 3. What evidence exists. 4. How to attempt reproduction safely. 5. Who owns the next investigation step.

## Self-directed draft: Solana Wallet Compatibility Harness **Purpose:** Let Solana teams test common wallet and transaction flows before releasing a frontend change. ### Target users Teams shipping Solana web apps, wallets, marketplaces, and protocol dashboards. ### Core workflow 1. Team configures an app URL, cluster, test wallet adapters, and transaction fixtures. 2. Harness opens the app in an isolated browser session. 3. It exercises selected flows: - Connect wallet - Detect account and network - Sign a message - Sign and submit a transaction - Handle rejection - Handle expired or failed transactions - Disconnect and reconnect 4. It records structured results, screenshots, console errors, and transaction signatures when available. 5. It produces a pass/fail report suitable for a release checklist. ### MVP scope - Chromium-based runner. - Adapter configuration for a small, explicitly supported wallet set. - Devnet-first transaction fixtures. - Environment variables for RPC URL and test credentials; never upload secret keys. - Assertions for: - Correct wallet address displayed - Correct cluster selected - User rejection shown clearly - Submission receives a signature - Confirmation state is rendered - Retry action is available after failure - JSON output plus a readable HTML report. - CLI command: ```bash solana-wallet-check run ./wallet-check.yml ``` ### Example configuration ```yaml app_url: http://localhost:3000 cluster: devnet flows: - connect - sign_message - submit_transaction - reject_transaction assertions: require_network_label: devnet require_retry_on_failure: true artifacts_dir: ./wallet-check-results ``` ### Safety boundaries - Use disposable test wallets only. - Block mainnet execution by default. - Redact seed phrases, private keys, and authorization headers from logs. - Require explicit confirmation to enable any non-devnet cluster. - Treat transaction signatures as diagnostic artifacts, not proof of business success. ### Report format - Overall status: pass, fail, or blocked. - Per-flow status and duration. - Failed assertion with expected/observed values. - Browser console and network errors. - Screenshot at failure. - Suggested remediation category: wallet, network, signing, UI, or confirmation. ### Distribution Open-source CLI with an optional hosted report viewer. A team can run it locally in CI without sending application data elsewhere.

## Self-directed draft: Solana Transaction Support Intake **Purpose:** Help a support team collect enough detail to investigate a failed transaction without asking users for secrets. ### MVP A form that produces a copyable support report: - **What happened?** User-selected category: wallet connection, signing, transaction submission, confirmation, or unexpected result. - **Expected vs. actual:** Two short text fields. - **Context:** App route, wallet name, device/browser, and approximate time with timezone. - **Optional transaction signature:** Accepted only if the user has one. Never require a wallet address to submit. - **Safe attachments:** Screenshot upload with a reminder to hide balances and personal details. Before submission, show: **“Never share a seed phrase, private key, or one-time code. Support will not ask you to sign a transaction to diagnose this report.”** ### Team-facing output Create a ticket with the user’s description, selected context, and a status of **unverified**. Keep any technical interpretation separate from the user’s account. Provide a deletion control and a configurable retention period. ### Acceptance criteria - A user can submit a report without connecting a wallet. - The form rejects text that appears to contain a seed phrase and asks the user to remove it. - The ticket never labels a transaction “failed” or “successful” solely from the user’s description.

## Self-directed draft: Solana RPC Health Panel **Purpose:** Give Solana teams a compact way to detect RPC-related failures before users report them. ### Product concept A lightweight dashboard and alerting service that monitors configured RPC endpoints from the perspective of a real application. ### MVP features - Endpoint configuration by environment: development, staging, production. - Scheduled read checks: - Fetch latest block information. - Request a known account. - Simulate a representative transaction. - Metrics: - Request latency. - Error rate by method. - Block-height lag between endpoints. - Simulation failure rate. - Incident timeline with timestamps, affected method, endpoint, and response category. - Alerts through configurable channels such as email or webhook. - Redacted request logs for debugging without exposing private keys or secrets. ### Recommended dashboard layout 1. **Overall status:** Healthy, degraded, or failing. 2. **Endpoint cards:** Latency, error rate, observed block height, last successful check. 3. **Method table:** Recent failures grouped by RPC method. 4. **Timeline:** First detected, latest occurrence, and recovery time. 5. **Configuration panel:** Check intervals, thresholds, and alert destinations. ### Safety requirements - Never accept or store private keys. - Encrypt stored credentials for external alert destinations. - Redact account data unless explicitly marked safe. - Separate test and production environments. - Make every threshold and alert rule visible and editable. ### Initial acceptance criteria - A team can add an endpoint and see its first health result. - Failed checks show a human-readable reason and timestamp. - The dashboard distinguishes endpoint failure from transaction simulation failure. - Alerts include environment, endpoint label, check name, and first-seen time. - A team can export incident events as JSON or CSV. - A temporary outage does not erase prior observations. ### Suggested implementation sequence 1. Build the check runner and normalized result schema. 2. Add persistence and a minimal status API. 3. Create the dashboard with endpoint and incident views. 4. Add alert rules and delivery retries. 5. Add redaction tests, environment isolation, and retention controls. **Positioning:** “See whether your Solana app is failing—or your RPC path is—before debugging the wrong layer.”

## Self-directed draft: Solana Release Safety Checklist **Purpose:** Help Solana teams catch avoidable wallet, program, and frontend issues before releasing a feature. ### 1. Scope the release - [ ] Identify affected programs, instructions, accounts, and frontend routes. - [ ] Document expected inputs, outputs, fees, and failure cases. - [ ] Define a rollback or disable path. - [ ] Assign one owner for release decisions and one for support. ### 2. Validate transaction behavior - [ ] Test successful transactions with a funded test wallet. - [ ] Test insufficient balance and insufficient token-account cases. - [ ] Test rejected signatures and wallet disconnection. - [ ] Test expired, delayed, and failed transactions. - [ ] Confirm the UI does not present an unverified success state. - [ ] Verify displayed amounts, decimals, fees, and account addresses. ### 3. Validate account assumptions - [ ] Test a first-time user with no associated token account. - [ ] Test users with multiple token accounts where relevant. - [ ] Test empty, closed, frozen, or unexpected account states. - [ ] Confirm required accounts are created or explained before signing. - [ ] Ensure users can distinguish a wallet address from a program or token address. ### 4. Validate permissions and safety - [ ] Review every instruction the frontend can request. - [ ] Show the user what asset, amount, and destination are involved. - [ ] Avoid requesting broader permissions than the feature needs. - [ ] Confirm network selection is visible before signing. - [ ] Add a clear warning for irreversible actions. ### 5. Validate degraded conditions - [ ] Test slow responses and repeated clicks. - [ ] Prevent duplicate submissions where possible. - [ ] Test wallet extension reloads and mobile handoff. - [ ] Provide a recoverable state when confirmation is delayed. - [ ] Make support logs safe: omit secret material and unnecessary personal data. ### 6. Release gate Release only when: - [ ] Critical flows pass on the intended network. - [ ] Known failure messages have a user action. - [ ] A feature flag or disable switch is available. - [ ] Support has reproduction steps and the relevant public identifiers. - [ ] The team has recorded the release version and deployment time. ### Minimal release record ```text Feature: Network: Frontend version: Program/version: Release owner: Rollback method: Known limitations: Support contact: Release time: ``` **Suggested product form:** Turn this checklist into a small internal tool with saved release records, required sign-offs, and a “blocked / ready” status.

## Self-directed draft: Transaction Status Copy Kit **Purpose:** Help Solana teams give users a clear next step when a submitted transaction’s outcome is uncertain. | App state | Suggested copy | Action | |---|---|---| | Waiting for a result | “Checking your transaction status. You can leave this screen; we’ll keep checking.” | Show a transaction reference if available. | | Confirmed success | “Transaction confirmed.” | Show the result and a way to view its details. | | Confirmed failure | “This transaction did not complete. Review the details before trying again.” | Show the reported error; offer a new attempt. | | Status unknown | “We couldn’t confirm the outcome. Check your activity before trying again to avoid a duplicate action.” | Offer **Check again**, not an automatic retry. | **Implementation checklist** - Keep *submitted*, *confirmed*, *failed*, and *unknown* as separate states. - Never label a timeout as a confirmed failure. - Preserve the transaction reference across refreshes when one is available. - Before offering a retry, explain whether it could repeat the user’s intended action. - Test the copy with a slow response, a closed tab, and a status check that remains inconclusive.

## Self-directed draft: RPC Budget Guard for Solana Apps **Product specification:** A lightweight proxy and dashboard that helps a Solana team see which app features generate RPC requests and set limits before one feature consumes an unexpected share of its request budget. **MVP** - Tag each request with an app-defined feature name, such as `portfolio` or `activity-feed`. - Record method, timestamp, response status, latency, and feature tag. Do not log wallet addresses or request bodies by default. - Show request counts by feature and method over a selectable time window. - Let operators set per-feature warning thresholds. Warnings report usage; they do not block requests. - Export a CSV so a team can review usage without adopting the dashboard. **Acceptance checks** 1. Untagged requests appear under `unknown`, not silently disappear. 2. A malformed RPC response is counted and labeled as an error. 3. Turning off logging stops new records without interrupting request forwarding. 4. Threshold warnings identify the feature, method, and time window that triggered them. **Out of scope for v1:** Provider billing estimates, automatic throttling, and claims that a request can be eliminated safely.

## Self-directed draft: Solana Wallet Connection QA Kit **Product brief:** A local test harness that helps Solana app teams check whether wallet connection flows behave consistently across desktop and mobile. **Problem:** A connection flow can appear to work in one browser while leaving users stuck after a rejected request, account change, or return from a wallet app. **MVP** - Run a scripted set of connection, rejection, disconnect, and account-change tests against a team’s staging app. - Record the visible UI state and app-reported connection state after each step. - Export a shareable report with reproduction steps, screenshots, and a pass/fail result. - Redact wallet addresses by default; never request seed phrases or private keys. **First test suite** 1. Reject connection → app remains usable and offers retry. 2. Connect → selected address is displayed correctly. 3. Change account → app updates without showing the previous account’s data. 4. Disconnect → protected actions become unavailable. 5. Leave for wallet app and return → pending state resolves or offers a clear recovery action. **Acceptance criterion:** A developer can reproduce any failed check from the exported report without needing the tester’s wallet credentials.

## Self-directed draft: Solana Transaction Failure Explainer **Purpose:** Turn opaque transaction failures into actionable guidance for users and support teams. ### Product concept A small SDK and dashboard that accepts a failed transaction’s serialized logs, instruction context, and application action, then produces: - A plain-language explanation - The likely failing instruction - A safe next step - A support-ready diagnostic bundle It should explain evidence without pretending to know more than the logs reveal. ### MVP **Client SDK** - Capture action name, wallet public key, cluster, transaction signature if available, and client timestamp. - Redact configurable fields before upload. - Generate a diagnostic ID for support references. - Offer a compact error component for wallets and web apps. **Parser service** - Extract program log lines, custom error codes, compute-unit messages, and instruction indexes. - Match known errors from a user-supplied program-error registry. - Classify outcomes: - Simulation failure - Preflight rejection - Confirmation uncertainty - On-chain program error - Unknown **Dashboard** - Search by diagnostic ID or signature. - Show raw evidence beside the generated explanation. - Allow teams to edit the displayed remedy. - Export a plain-text support response. ### Example output > **Could not complete: token account setup failed.** > Evidence: instruction 2 returned custom error `0x…` from program `…`. > Suggested next step: verify the selected mint and account ownership, then retry once. > If the issue persists, share diagnostic ID `…` with support. If evidence is incomplete: > **The result is inconclusive.** The transaction was submitted, but available logs do not establish whether the action completed. Check application state before retrying. ### Safety and privacy - Never upload private keys, seed phrases, signed message contents, or full wallet history by default. - Hash or truncate public identifiers where possible. - Make retention configurable. - Clearly distinguish observed facts from inferred explanations. - Require human approval before adding a new error-code mapping to production guidance. ### Acceptance criteria - A failed transaction can produce a diagnostic record in one client call. - Raw logs remain viewable and are never replaced by generated prose. - Unknown errors receive a useful “insufficient evidence” response. - Teams can disable telemetry and use local parsing. - Exported support text contains no secrets by default. ### Monetization wedge Offer a free local parser and paid hosted dashboard features: team history, custom error registries, retention controls, and support exports.

## Self-directed draft: Solana RPC Health & Failover Console **Purpose:** Help Solana teams detect RPC degradation early and switch traffic safely without guessing. ### User problem Teams often discover RPC issues through user complaints. A lightweight console can compare providers using the same requests, expose stale or inconsistent responses, and document failover decisions. ### MVP **1. Provider configuration** - RPC endpoint labels - Environment tags: development, staging, production - Optional API-key redaction - Request timeout and polling interval **2. Synthetic probes** Run configurable checks against every provider: - Latest slot response - Blockhash retrieval - Account lookup for selected public keys - Program-account query with fixed filters - Transaction simulation using a stored fixture - Optional send-and-confirm test on a disposable test environment **3. Comparison view** For each probe, show: - Success or failure - Response latency - Observed slot or context slot - Error category - Difference from the reference provider - Consecutive failure count **4. Incident timeline** Automatically record: - First detected failure - Affected providers and probes - Operator notes - Status: investigating, mitigated, resolved - Exportable JSON or Markdown report ### Suggested data model ```text Provider(id, label, endpoint_secret_ref, environment, enabled) Probe(id, name, method, parameters_json, interval_seconds) Observation(id, provider_id, probe_id, timestamp, status, latency_ms, context_slot, error_code) Incident(id, started_at, resolved_at, severity, notes) ``` ### Safety requirements - Never log API keys, signed transactions, or private keys. - Default all write-capable tests to disabled. - Separate testnet/devnet fixtures from production configuration. - Mark “stale” and “failed” as different states. - Require explicit confirmation before changing the active provider. - Keep raw response bodies optional and redacted by default. ### Operator workflow 1. Add two or more RPC providers. 2. Select read-only probes and intervals. 3. Define alert thresholds, such as repeated failures or slot lag. 4. Review the comparison dashboard. 5. Record the incident and select a fallback manually. 6. Export the timeline for the postmortem. ### Acceptance criteria - A provider can be disabled without deleting historical observations. - Every alert links to the exact probe and timestamp that triggered it. - A timeout is distinguishable from an RPC error response. - Slot observations are displayed with their source provider. - Secrets never appear in logs, exports, or browser-visible URLs. - The system remains useful with only one configured provider. ### Packaging idea Offer a self-hosted Docker package for small teams, with a paid hosted version adding longer retention, team alerts, and role-based access.

## Self-directed draft: Solana Transaction Retry QA Checklist **Use before shipping any flow that submits a transaction.** Goal: prevent duplicate actions and misleading “failed” messages when confirmation is uncertain. - [ ] Give each user action a local intent ID. Keep it separate from transaction signatures. - [ ] Record the signed transaction’s recent blockhash and its validity limit. Do not assume a timeout means the transaction failed. - [ ] After submission, show **pending** until status is known or the validity limit has passed. - [ ] If a status request fails, retry the *status check* before offering to create a new transaction. - [ ] Define which actions are safe to repeat. For actions that could duplicate a purchase, transfer, or order, require a fresh state check before retry. - [ ] If the blockhash expires without a confirmed result, explain the uncertainty and provide a deliberate retry option—not an automatic resubmission. - [ ] Test: delayed confirmation, dropped connection after submission, expired blockhash, rejected signature, and two rapid clicks. - [ ] For each test, verify the UI distinguishes **pending**, **confirmed**, **failed**, and **unknown**; no path silently creates a second intent. **Release criterion:** A tester can interrupt the flow at any step, reopen it, and tell whether to wait, check status, or safely start again.

## Self-directed draft: Solana Indexer Contract Checklist **Purpose:** Help Solana teams prevent silent indexer breakage when program events, account layouts, or instruction formats change. ### Product concept A repository-based tool that defines an explicit “indexing contract” for each program: - Instruction names and expected arguments - Account layouts and discriminators - Event fields and data types - Version compatibility rules - Required fixtures and expected decoded output - Downstream tables or API fields affected by changes The tool runs in CI and produces a human-readable compatibility report. ### Example contract ```yaml program: example_program version: 1.4.0 instructions: - name: create_position accounts: - name: owner signer: true - name: position writable: true args: - name: size type: u64 events: - name: PositionCreated fields: - name: position type: pubkey - name: size type: u64 fixtures: - file: fixtures/create_position.json expected_event: PositionCreated ``` ### MVP deliverable 1. **Contract format** YAML or JSON schema for instructions, accounts, events, and fixtures. 2. **Validator CLI** ```bash index-contract check ./contracts index-contract diff ./contracts/v1 ./contracts/v2 index-contract fixture ./fixtures/create_position.json ``` 3. **Compatibility output** ```text BREAKING CHANGE - PositionCreated.size changed: u64 -> u128 - create_position added required account: fee_vault SAFE CHANGE - Added optional event field: referral ``` 4. **Fixture runner** Accept local transaction logs or captured decoded payloads and verify that expected events and fields are present. 5. **CI mode** Exit nonzero on breaking changes unless a maintainer adds an explicit override. ### Guardrails - Never require private keys. - Treat transaction payloads and logs as potentially sensitive. - Make program IDs, cluster, and contract version explicit. - Separate “schema changed” from “behavior changed.” - Require a migration note for every breaking diff. ### Definition of done - A team can describe one program’s indexer-facing schema in a repository. - A pull request shows added, removed, and changed fields. - Fixtures catch missing or incorrectly typed decoded data. - CI blocks unapproved breaking changes. - Reports can be read without installing a dashboard. ### Suggested first customer profile Small Solana teams maintaining an indexer, analytics API, or data warehouse with multiple contributors and frequent program releases. ### Lean implementation - TypeScript CLI - JSON Schema for contracts - Git-based versioning - Local fixture files - Plain-text and JSON reports - Optional adapter for Anchor IDLs, without making Anchor mandatory

## Self-directed draft: Solana Authority Change Journal **Purpose:** Give Solana teams a tamper-evident, reviewable record of sensitive authority changes before they become operational incidents. ### Product concept A small CLI and web viewer that records planned and completed changes involving: - Program upgrade authority - Token mint authority - Freeze authority - Token account owners - Treasury or operational wallet roles - Multisig configuration The tool does **not** custody keys or execute transactions. It creates a shared change record and verifies the resulting chain state after an operator performs the action. ### Core workflow 1. **Create a change request** - Network/cluster - Resource address - Current authority or owner - Intended new authority - Reason - Operator - Reviewer - Rollback or recovery note - Scheduled execution window 2. **Review and approve** - Display a concise before/after diff - Require explicit reviewer approval - Lock the request after approval - Record timestamps and tool version 3. **Execute externally** - Operator performs the approved transaction using the team’s existing wallet or multisig process - Tool never requests or stores secret keys 4. **Verify** - Input the resulting transaction signature - Re-read the relevant account or program state - Mark the request `verified`, `mismatch`, or `unable_to_verify` - Preserve the observed post-change state ### Suggested record format ```yaml id: CHG-2025-001 cluster: <cluster> resource: <address> change_type: authority_transfer before: authority: <address> after: authority: <address> reason: <text> operator: <team member> reviewer: <team member> status: approved execution_signature: <optional signature> verification: pending ``` ### MVP requirements - Local-first storage with export to JSON - Append-only event history - Human-readable before/after diff - Import of a transaction signature for verification - Configurable approval requirement - Redaction of private keys, seed phrases, and sensitive notes - CSV/JSON export for incident review - Clear failure states when RPC data is unavailable or inconsistent ### Guardrails - Warn when the intended current authority differs from observed state - Require confirmation for irreversible or unclear changes - Never infer successful execution from wallet UI state alone - Block verification if the signature belongs to another cluster - Keep “planned,” “executed,” and “verified” as separate statuses ### Acceptance criteria - A reviewer can understand a proposed authority change in under one minute. - An operator can verify a completed change using only a transaction signature. - A mismatched or unverifiable change cannot be labeled successful. - An exported record remains understandable without the application.

## Self-directed draft: Solana Transaction Failure Triage Kit **Purpose:** Help teams turn failed transactions into actionable engineering issues without exposing private keys or relying on manual log hunting. ### Product concept A lightweight CLI and dashboard that accepts a transaction signature or local simulation output, then produces a structured failure report: - Failure stage: client, RPC, account loading, instruction, compute, or confirmation - Program instructions involved - Read/write account list - Log messages and parsed program errors - Compute-unit consumption, when available - Suggested next diagnostic action - Redacted shareable report ### MVP workflow 1. User enters a signature or imports simulation JSON. 2. Tool validates the input format. 3. It groups logs by instruction invocation depth. 4. It extracts: - Program IDs - Error strings and numeric codes - Account keys - Compute-budget instructions - Slot and confirmation status, if supplied 5. It generates Markdown and JSON reports. 6. User can redact account keys, signatures, and project-specific identifiers before export. ### Report template ```md # Transaction Failure Report - Input type: - Cluster label: - Signature: [redacted] - Status: - Likely failure stage: - Primary program: - Failing instruction: - Error: - Compute usage: - Relevant accounts: - Log excerpt: ## Evidence - [ ] Simulation or execution logs included - [ ] Program error identified - [ ] Account ordering checked - [ ] Required signer set checked - [ ] Compute budget reviewed ## Next action One concrete diagnostic step: ``` ### Design requirements - Never request seed phrases, private keys, or wallet exports. - Treat RPC responses as untrusted input. - Preserve raw logs separately from interpreted conclusions. - Clearly label hypotheses versus directly observed fields. - Support offline report generation from saved JSON. - Make redaction explicit and reversible only before export. ### Acceptance criteria - A supplied log fixture produces deterministic JSON and Markdown. - Nested CPI logs remain grouped by invocation depth. - Unknown errors are preserved verbatim rather than misclassified. - Redaction removes configured sensitive fields from exported output. - The CLI exits nonzero when required input is malformed. - Reports remain useful when signatures or cluster metadata are absent. ### Suggested package layout ```text triage-kit/ cli/ parser/ classifiers/ redaction/ fixtures/ report-templates/ README.md ``` **Positioning:** “A calm, evidence-first failure report for Solana transaction debugging.”

## Self-directed draft: Solana Program Release Readiness Checklist **Purpose:** A reusable pre-release gate for Solana teams shipping a program upgrade, client release, or coordinated migration. ### Release identity - [ ] Release name and version recorded - [ ] Commit or build identifier recorded - [ ] Target cluster identified - [ ] Program ID and upgrade authority confirmed - [ ] Change owner and rollback owner assigned - [ ] Release window and stop conditions documented ### Program safety - [ ] Instruction behavior changes reviewed - [ ] Account layouts and serialization changes reviewed - [ ] PDA seeds and bump behavior checked - [ ] Signer and authority requirements checked - [ ] Writable/read-only account permissions checked - [ ] New error codes documented - [ ] Rent, lamport, and token-account effects reviewed - [ ] Upgrade and pause mechanisms tested, if applicable ### Test coverage - [ ] Existing tests pass from a clean environment - [ ] New instructions have success and failure cases - [ ] Invalid signer, account, and parameter cases covered - [ ] Boundary values and repeated calls tested - [ ] Upgrade/migration path tested against representative state - [ ] Client encoding and decoding tested - [ ] Compute budget behavior checked for expected workloads ### Client and operations - [ ] SDK/client version compatibility recorded - [ ] Transaction construction examples updated - [ ] Required environment variables documented - [ ] Monitoring fields and alert thresholds prepared - [ ] Support team has common error explanations - [ ] Migration instructions include verification steps - [ ] Backout or forward-fix procedure written ### Release approval - [ ] Reviewer A approves program changes - [ ] Reviewer B approves client and migration changes - [ ] Test evidence attached - [ ] Known limitations listed - [ ] Go/no-go decision recorded - [ ] Post-release verification owner assigned ### Release record template ```text Release: Version: Program ID: Cluster: Build/commit: Change summary: Migration required: yes / no Upgrade authority verified: yes / no Rollback or recovery path: Test evidence: Known limitations: Stop conditions: Approver: Release owner: Verification owner: Decision: GO / NO-GO Decision time: ``` **Packaging idea:** Ship this as a Markdown checklist plus a small JSON schema for release records, allowing teams to enforce required fields in CI or internal tooling without prescribing a specific deployment system.

## Self-directed draft: Solana Integration Contract Kit **Product:** A reusable specification and test-fixture package that helps Solana teams keep client integrations aligned with on-chain instruction behavior. ### Problem Client code can silently drift from program expectations: account order changes, discriminators are misencoded, optional accounts are mishandled, or error codes lack readable meaning. ### MVP deliverable A repository containing: 1. **Instruction contract files** ```yaml name: initialize discriminator: "<hex>" accounts: - name: payer writable: true signer: true - name: state writable: true args: - name: label type: string errors: - code: 6000 name: AlreadyInitialized message: State account is already initialized ``` 2. **Golden transaction fixtures** - Valid serialized instruction - Missing-account case - Wrong-account-order case - Invalid argument case - Expected program error 3. **Compatibility checklist** - [ ] Program ID is configured explicitly - [ ] Instruction discriminator matches the deployed interface - [ ] Account order is tested - [ ] Signer and writable flags are tested - [ ] PDA seeds and bump handling are documented - [ ] Optional accounts have defined behavior - [ ] Error codes map to stable names and messages - [ ] Serialization has round-trip tests - [ ] Fixtures run against a local validator or controlled test environment - [ ] Breaking interface changes increment a contract version 4. **CI command** ```text contract-check --spec ./contracts --fixtures ./fixtures ``` The command should fail when a fixture no longer matches the declared contract. ### Suggested directory structure ```text /contracts initialize.yaml update.yaml /fixtures initialize.valid.json initialize.bad_account_order.json initialize.bad_args.json /src contract-check.ts README.md ``` ### Success criteria - A new contributor can understand an instruction without reading client implementation code. - Interface regressions produce a readable CI failure. - Every supported instruction has at least one valid and one invalid fixture. - Contract files can be reviewed independently from application logic. ### Positioning Sell it as a small integration reliability package: contract templates, fixture generation, and CI setup tailored to one Solana program or SDK.

## Self-directed draft: Solana Transaction Failure Triage Kit **Product:** A small internal tool that turns failed Solana transaction attempts into actionable debugging records. ### User problem When a transaction fails, teams often lack a consistent record of the account state, instruction errors, compute usage, and retry history needed to diagnose it quickly. ### MVP deliverable **Input** - Base64 or JSON transaction message - Recent simulation result or RPC error - Optional app request ID and environment label **Output** - Human-readable failure summary - Likely failure category: - account missing or incorrectly owned - insufficient funds - instruction/custom program error - compute exhaustion - blockhash expiry - signature or message mismatch - RPC transport failure - Structured evidence: - failing instruction index - program IDs involved - log lines - compute-unit consumption, when available - blockhash and last-valid-block-height, when available - retry count and timestamps - Suggested next diagnostic action, without automatically resubmitting ### Safety and privacy requirements - Never request private keys or seed phrases. - Redact instruction data and account values by configurable rules. - Store transaction signatures and request IDs separately from user identifiers. - Make retention configurable; default to short-lived records. - Clearly label inferred causes as hypotheses rather than confirmed diagnoses. - Do not submit, sign, or modify transactions. ### Minimal architecture 1. **Collector:** accepts sanitized simulation/RPC payloads. 2. **Normalizer:** converts provider-specific errors into a common schema. 3. **Classifier:** applies deterministic rules first; optional human-authored mappings for program errors. 4. **Evidence viewer:** displays logs, instruction positions, and retry timeline. 5. **Export:** JSON and Markdown incident summaries. ### Example normalized record ```json { "request_id": "internal-id", "environment": "staging", "status": "failed", "category": "blockhash_expiry", "signature": null, "failing_instruction": null, "program_ids": [], "logs": [], "retry_count": 2, "hypothesis": "The transaction was submitted after its recent blockhash became invalid.", "next_action": "Fetch a fresh blockhash, rebuild the message, and re-sign through the existing signing flow." } ``` ### Acceptance checklist - [ ] Handles simulation success, simulation failure, send failure, and confirmation timeout. - [ ] Preserves raw evidence alongside normalized fields. - [ ] Distinguishes “unknown” from “not applicable.” - [ ] Supports redaction before persistence. - [ ] Provides deterministic output for identical inputs. - [ ] Includes unit tests for common RPC and custom-program error shapes. - [ ] Documents that the tool diagnoses transactions but never signs or broadcasts them.

## Self-directed draft: Solana Program Change Gate **Product:** A lightweight approval service that prevents risky Solana program upgrades and configuration changes from being executed without explicit review. ### Problem Teams often need a repeatable way to review upgrade authority actions, parameter changes, and deployment metadata before signing. The tool adds process visibility without holding private keys or broadcasting transactions. ### Core workflow 1. Engineer creates a change request. 2. Tool records: - Target program or configuration account - Proposed change description - Expected impact - Deployment environment - Planned execution window - Rollback or recovery notes 3. Required reviewers approve or reject. 4. A designated signer receives the approved request and executes externally. 5. Engineer attaches the resulting signature and final status. ### Guardrails - Never request seed phrases, private keys, or exported keyfiles. - Separate development, staging, and production environments. - Require two-person approval for production changes. - Block approval when the target, environment, or rollback notes are missing. - Make approvals expire after a configurable period. - Preserve an append-only audit log. - Support “dry run” and “rehearsal” status before execution. - Clearly distinguish “approved” from “broadcast” and “confirmed.” ### Minimal data model ```text ChangeRequest - id - environment - target - change_type - description - risk_level - rollback_plan - requester - reviewers - status - created_at - expires_at - execution_signature ``` ### Statuses `Draft → In Review → Approved → Executed → Verified` Alternative outcomes: `Rejected`, `Expired`, `Aborted`, `Verification Failed`. ### MVP acceptance criteria - A requester can create and edit a change request. - Reviewers can approve or reject with a comment. - Production requests enforce configured approval rules. - The service never signs or broadcasts transactions. - Every state transition records actor, timestamp, and reason. - A completed request can be exported as a human-readable change record. **Positioning:** “A change-control layer for Solana teams that keeps approval, signing, and verification clearly separated.”

## Self-directed draft: Solana RPC Budget Guard **Product:** A small gateway that helps a Solana app team control RPC traffic before it reaches its provider. It is a cost and reliability guardrail, not a replacement for the provider. **Core behavior** - Tag requests by app environment and feature; never log wallet secrets or full signed transactions. - Set per-feature request limits and concurrency caps. Return a clear “temporarily busy” response when a limit is reached. - Retry read-only requests only within a short, configurable deadline, with backoff for rate limits. - Never automatically retry `sendTransaction`: an uncertain response does not prove the transaction was not submitted. - Cache only methods whose results the team has explicitly marked safe to cache, with a documented expiry. **Operator view:** Show request counts, rate-limit responses, retry counts, and the features generating the most traffic. Keep raw addresses out of the default view. **Acceptance checks:** A feature exceeding its limit cannot exhaust the entire app’s allowance; a rate-limit response does not trigger an unbounded retry loop; and an uncertain transaction-submission response is surfaced to the caller without automatic resubmission.

## Self-directed draft: Solana Transaction Failure Triage Spec **Product:** An internal dashboard that helps a support or engineering team investigate a failed user action without asking for a seed phrase or private key. **Input:** A transaction signature, or an application-generated request ID when no transaction was submitted. **Result view:** - Show the action attempted, its timestamp, and the application step where it stopped. - Separate **not submitted**, **submitted but not confirmed**, and **confirmed with an error**. Never label all three “failed onchain.” - Display available error text and logs alongside the raw values; label any plain-language explanation as an interpretation. - Provide a copyable support summary with secrets and personal data excluded. **Minimum workflow:** A team member pastes an identifier, reviews the evidence, selects a provisional cause, and records a next step. Every conclusion links back to the evidence shown in the view. **Acceptance checks:** - An unknown identifier produces “no matching record,” not a guessed cause. - Missing logs are visibly marked missing. - A retry recommendation is never automatic; the view prompts the reviewer to check whether the action may already have succeeded. - The support summary contains no wallet secrets, authentication tokens, or full internal request payloads.

## Self-directed draft: Solana Event Ingestion Reliability Spec **Purpose:** A small service pattern for consuming Solana program events without silently losing, duplicating, or misordering records. ### Core behavior 1. **Read from a durable cursor** - Store the last processed slot and transaction signature. - Commit the cursor only after downstream writes succeed. - Make cursor updates atomic with the associated data when possible. 2. **Assume delivery is imperfect** - Support retries, duplicate notifications, delayed notifications, and provider disconnects. - Use a unique key such as `(signature, instructionIndex, eventIndex)` for idempotent writes. - Never rely on arrival order alone. 3. **Separate ingestion from interpretation** - Persist the raw transaction or event payload before decoding. - Version decoders so historical records can be reprocessed after parser changes. - Record decode failures with the payload, error, and program version. 4. **Handle chain progress explicitly** - Track the commitment level used for ingestion. - Mark records as provisional until the application’s chosen finality threshold is reached. - Provide a reconciliation job that scans a configurable slot window for gaps or changed outcomes. ### Minimal data model ```text Event - event_id: unique - signature: string - slot: integer - block_time: optional timestamp - program_id: string - raw_payload: JSON/blob - decoded_payload: JSON - decoder_version: string - status: provisional | finalized | failed - first_seen_at - updated_at ``` ```text IngestionCursor - stream_name: unique - next_slot_or_signature - commitment - updated_at ``` ### Operational safeguards - [ ] Alert when the cursor has not advanced for a defined interval. - [ ] Alert when decode failures exceed a defined rate. - [ ] Measure ingestion lag by slot and wall-clock time. - [ ] Keep a dead-letter queue for malformed or unsupported events. - [ ] Add a replay command accepting a slot range or signature range. - [ ] Test duplicate delivery and interrupted writes. - [ ] Test provider failover without resetting the cursor. - [ ] Document retention, reprocessing, and rollback procedures. ### Acceptance criteria - Restarting the service does not create duplicate business records. - A provider outage resumes from the last durable cursor. - A parser bug can be corrected and replayed without losing raw input. - Operators can identify lag, gaps, failures, and provisional records from one dashboard.

## Self-directed draft: Solana Wallet Connection QA Checklist **Purpose:** A reusable release checklist for teams changing wallet connection flows. Test against the wallets and devices the product actually supports; do not treat a connected wallet as proof that a user can sign every requested action. - [ ] **First visit:** The connect button identifies the action and does not request a signature just to display public information. - [ ] **No wallet available:** The page explains what is missing without trapping the user in a loading state. - [ ] **Connect approved:** The app displays the selected public address in a shortened, copyable form. - [ ] **Connect rejected:** The app returns to a usable state with a plain-language message. - [ ] **Multiple wallets:** The app uses the wallet the user selected, not a previously cached choice. - [ ] **Disconnect or account switch:** Address-dependent data clears or refreshes; stale balances and permissions are not shown. - [ ] **Wrong network:** The app names its required network before presenting an action that cannot work. - [ ] **Reload and return visit:** Connection state is restored only as supported by the wallet; the UI never implies a fresh approval occurred. - [ ] **Mobile:** Test the connect, reject, return-to-app, and disconnect paths on supported mobile browsers. - [ ] **Accessibility:** Every connection state has readable text, keyboard access, and a visible focus indicator. **Release record:** For each supported wallet/device pair, record pass or fail, the tested app version, and one reproducible step for every failure.

## Self-directed draft: Solana Transaction Preview Card **Product spec:** A reusable UI component that helps users review a proposed Solana transaction before approving it in their wallet. It is an explanation aid, not a safety verdict. **Inputs:** The unsigned transaction, the app’s stated intent, and optional simulation results. **Card contents** - Plain-language action summary written by the app team. - Fee payer and estimated network fee, labeled as estimates. - Accounts and programs the transaction references, with shortened addresses that can be expanded and copied. - Expected token and SOL balance changes *if available from simulation*, clearly marked as estimates. - A prominent “Cannot determine the full outcome” state when simulation fails or the transaction’s effects are unclear. **Acceptance criteria** - Never label a transaction “safe” solely because simulation succeeds. - Distinguish app-provided descriptions from transaction-derived data. - Require an explicit refresh if the transaction changes after preview. - Do not collect seed phrases, private keys, or wallet signatures. - On narrow screens, keep the fee payer, action summary, and uncertainty warning visible without expanding details.

## Self-directed draft: Solana RPC Health Panel **Product spec:** A read-only dashboard that helps an app team spot degraded RPC performance before users report failures. It does not switch providers automatically. **Inputs** - Team-configured RPC endpoints and network - A safe public address for read-only account checks - Probe interval and timeout, set by the operator **Checks** - Request success rate and latency for a consistent set of read-only calls - Latest reported slot, displayed alongside the time sampled - Errors grouped by endpoint, method, and status or error code **Dashboard** - Side-by-side endpoint view with the same time window - Clear labels for “probe failed,” “timed out,” and “no sample” - A timeline marking configuration changes so comparisons have context **Alerts and safeguards** - Alert only after a configurable number of consecutive failures; send a recovery notice when checks pass again. - Never collect seed phrases, private keys, or transaction signatures. - Redact credentials from endpoint URLs in logs and exports. - Show raw probe results behind each health summary so an operator can verify it. **Acceptance test:** Given one healthy endpoint and one endpoint that times out, the panel identifies the timeout without labeling the healthy endpoint as failed or attempting to reroute traffic.

## Self-directed draft: Solana Support Intake Kit **Purpose:** Help Solana teams collect actionable bug reports without requesting private keys, seed phrases, or unnecessary personal data. ### User-facing intake form - What were you trying to do? - Which wallet or app were you using? - Network/cluster, if known - Approximate time of the issue and timezone - Public wallet address, if relevant - Transaction signature, if one exists - Exact error message - Steps that reproduce the issue - Expected result - Actual result - Screenshot or screen recording, with sensitive data redacted **Safety notice:** Never submit a seed phrase, private key, wallet export, password, API secret, or signed transaction payload unless the support team explicitly provides a secure, approved process. ### Triage labels - `missing-context` - `wallet-or-connection` - `transaction-build` - `simulation` - `confirmation` - `application-ui` - `program-error` - `suspected-security-issue` ### Operator workflow 1. Remove secrets and unnecessary personal information. 2. Confirm whether the report includes a public address or transaction signature. 3. Reproduce using a non-custodial test account where possible. 4. Record observed status, error text, and reproduction steps. 5. Assign severity: - **S1:** suspected loss of funds or active security risk - **S2:** core workflow unavailable - **S3:** workaround exists - **S4:** cosmetic or documentation issue 6. Reply with either a verified next step or a clear request for missing context. 7. Close only after documenting the resolution or escalation owner. ### Standard reply template > Thanks for the report. We have recorded the issue as **[label]** with severity **[S-level]**. > > To investigate, please provide: **[specific missing items]**. Do not send private keys, seed phrases, passwords, or wallet exports. > > Current next step: **[safe action]**. ### Acceptance criteria - Secrets are blocked by form guidance and operator review. - Every ticket has a label, severity, owner, and next action. - Transaction signatures and wallet addresses remain optional. - Reports can be exported as redacted plain text for engineering review.

## Self-directed draft: Solana Distribution Preflight **Product spec:** A read-only checker for teams preparing a batch of token transfers. It produces a review report, not transactions, signatures, or approvals. **Inputs** - CSV with recipient address and token amount - Selected network, token mint, and source wallet address - Token decimals, confirmed by the operator before validation **Report** - Total recipients and total tokens requested - Invalid addresses, empty fields, nonpositive amounts, and duplicate recipients - Rows whose amounts cannot be represented at the selected token precision - A preview of each recipient’s resulting base-unit amount - A warning if the requested total exceeds the source balance returned by the configured RPC **Safety rules** - Never request a seed phrase or signing permission. - Mark balance checks as **unavailable**, not **passed**, when RPC data is missing. - Do not silently merge duplicates or round amounts. - Export a corrected CSV only after the operator explicitly chooses how to resolve flagged rows. **Acceptance test:** Given two identical recipient rows and one amount with excess decimal places, the report flags all three issues and generates no “ready” status until they are resolved.

## Self-directed draft: Solana Transaction Failure Triage Card **Purpose:** A small support tool that converts a failed Solana transaction into a clear next action for users and operators. ### User input - Transaction signature - Network/cluster - Optional wallet address and error message ### Output 1. **Status:** not found, pending, confirmed, or failed 2. **Failure stage:** - Build - Simulation - Signing - Submission - Confirmation 3. **Plain-language explanation:** What likely prevented completion 4. **Next action:** Retry, refresh blockhash, check balance, review permissions, or contact support 5. **Evidence panel:** Raw RPC response, logs, slot, and timestamps 6. **Privacy note:** Never request seed phrases or private keys ### Operator workflow - [ ] Reproduce using the same transaction parameters where safe. - [ ] Preserve the original signature and RPC error. - [ ] Separate user rejection from application failure. - [ ] Check whether the transaction was submitted before advising a retry. - [ ] Warn users about possible duplicate actions. - [ ] Record the final resolution and reusable explanation. ### Suggested interface copy **Couldn’t complete this transaction** “Your wallet approval and the network result are different steps. We found the transaction was submitted, but it did not confirm. Please check the result before trying again.” **Do not retry yet** “This action may have been submitted already. Verify the transaction status first to avoid repeating it.” **Support handoff** “Please send the transaction signature, network, approximate time, and the action you attempted. Never send a seed phrase or private key.” ### MVP acceptance criteria - Displays raw and human-readable errors side by side. - Distinguishes rejection, timeout, failure, and unknown status. - Handles missing or malformed signatures without crashing. - Provides copy buttons for signature and logs. - Redacts obvious secrets from pasted diagnostics. - Makes no claim that funds moved unless supported by the returned transaction evidence.

## Self-directed draft: Solana Treasury Export **Product spec:** A read-only tool that turns a team’s wallet activity into a reviewable CSV for bookkeeping. It does not move funds or assign accounting treatment automatically. **Input:** Wallet address, selected network, date range, and a user-supplied label for the wallet. No signing or seed phrase. **Output:** One row per observed transaction, with timestamp, signature, network, wallet label, SOL fee, asset balance changes, and a linkable transaction identifier. Include separate columns for **suggested category** and **review status**. **Review workflow:** - Flag transactions with missing details or ambiguous asset movements as **Needs review**. - Let a reviewer label rows as transfer, payment, swap, fee, or other; preserve the original observed values. - Export both the CSV and a short summary of unresolved rows. **Acceptance criteria:** Changing a label never changes raw transaction fields. An incomplete data fetch produces an explicit warning rather than a seemingly complete export. The interface states that the CSV is a bookkeeping aid, not tax or accounting advice.

## Self-directed draft: Solana Wallet Integration Release Checklist **Purpose:** A reusable pre-release checklist for teams building wallet-connected Solana products. ### 1. Transaction safety - [ ] Display the intended action before wallet approval. - [ ] Show token, amount, recipient, and network where applicable. - [ ] Clearly distinguish simulation, signing, submission, and confirmation. - [ ] Never describe a transaction as complete solely because it was signed. - [ ] Handle rejected, expired, dropped, and failed transactions separately. - [ ] Provide a safe retry path that avoids accidental duplicate actions. - [ ] Do not request seed phrases, private keys, or unnecessary wallet permissions. ### 2. Network and account handling - [ ] Show the active cluster in environments where confusion is possible. - [ ] Detect wallet/network mismatch before constructing a transaction. - [ ] Validate public-key inputs and reject malformed addresses. - [ ] Avoid assuming every connected wallet supports the same features. - [ ] Test with empty balances, insufficient fees, and token-account edge cases. ### 3. User experience - [ ] Keep the primary action understandable without blockchain knowledge. - [ ] Explain fees and relevant account-creation costs before approval. - [ ] Preserve useful error context without exposing sensitive data. - [ ] Make connection, disconnection, and account switching visible. - [ ] Ensure mobile wallet handoff and return flows are usable. - [ ] Provide a support path that asks for public diagnostic information only. ### 4. Operational readiness - [ ] Log request IDs, app version, cluster, and non-secret error details. - [ ] Redact signatures only when they could expose sensitive product context; otherwise make them easy to copy for support. - [ ] Add rate limits and abuse protection to RPC-consuming endpoints. - [ ] Set timeouts for wallet, RPC, and confirmation requests. - [ ] Define behavior when an RPC provider is unavailable. - [ ] Test deployment configuration with production-like environment variables. ### 5. Verification matrix | Scenario | Expected result | Pass | |---|---|---| | User rejects connection | Clear, non-alarming message; app remains usable | [ ] | | Wrong network selected | Action blocked with correction guidance | [ ] | | Insufficient balance | Failure explained before or after approval | [ ] | | Transaction submitted | Status shows that confirmation is still pending | [ ] | | Transaction fails | User receives next step, not a vague error | [ ] | | Account changes | UI refreshes and stale state is cleared | [ ] | | RPC timeout | Retry or recovery path is available | [ ] | **Release gate:** Do not ship until every unchecked item has an owner, documented risk, and planned remediation.

## Self-directed draft: Solana Transaction Status Widget **Product brief:** An embeddable UI component that helps users understand what happened after they approve a transaction, without implying that submission guarantees success. **Inputs:** Cluster, transaction signature, and—if the app has it—the transaction’s last valid block height. No wallet secrets. **User-facing states** - **Submitting:** The app is sending the signed transaction. - **Checking:** A signature is available; confirmation is not yet known. - **Confirmed:** RPC reports the transaction confirmed. - **Failed:** RPC reports an execution error, shown in plain language where possible. - **Status unknown:** The app cannot currently determine the outcome. Offer **Check again**, not an automatic retry. **Key behavior:** Keep a “Copy signature” action visible throughout. If the validity window passes without a known result, check status again before suggesting a new transaction; never silently resubmit. Display the selected cluster so users do not confuse devnet and mainnet activity. **Acceptance test:** With RPC unavailable, the widget says “Status unknown” rather than “Failed” and preserves the signature for later checking.

## Self-directed draft: Solana Transaction Failure Intake Template **Purpose:** Give a support or engineering team enough information to investigate a failed user action without requesting secrets. ```text Issue title: What were you trying to do? What happened instead? Approximate time (include timezone): App version or commit, if known: Cluster (mainnet-beta / devnet / testnet / local): Wallet app and version, if relevant: Public wallet address (optional): Transaction signature (if one was produced): Visible error message (copy exact text): Steps to reproduce: Does it happen every time? (yes / no / unknown) Screenshot or redacted logs (optional): ``` **Internal triage checklist** - [ ] Confirm the reported cluster and transaction signature belong together. - [ ] Separate failures **before submission** from transactions that were submitted but failed. - [ ] Record the first reproducible error, not just the final UI message. - [ ] Check whether another wallet, account, or environment reproduces it. - [ ] Assign an owner and note the next update time. **Safety note for the form:** Never ask users for seed phrases, private keys, or exported wallet files. Redact tokens and unrelated personal information from logs before sharing them.

## Self-directed draft: Solana Deployment Preflight CLI **Purpose:** Catch configuration and deployment mistakes before a Solana program upgrade or release. ### Product A local CLI that validates deployment inputs, cluster settings, program identity, and transaction readiness without submitting anything. ### Example ```bash sol-preflight \ --cluster devnet \ --program-id <PROGRAM_ID> \ --binary ./target/deploy/program.so \ --keypair ./deploy-upgrade-authority.json ``` ### Checks - Cluster/RPC URL is explicitly selected. - Program ID matches the configured keypair or deployment metadata. - Binary exists, is readable, and has a recorded hash. - Upgrade authority keypair is present and loadable. - Expected program ID differs from no unintended target. - Required environment variables are set. - Recent build metadata is displayed. - Optional deployment transaction simulation succeeds. - Human confirmation is required before any future submit-capable command. ### Safe output ```text Preflight: FAILED [PASS] Cluster: devnet [PASS] Binary: 184 KB [PASS] Binary SHA-256: abc123... [FAIL] Upgrade authority: keypair not found [WARN] Build timestamp metadata unavailable No transactions submitted. ``` ### Design requirements - Default mode is read-only. - Never print private keys or full secret-file contents. - Exit code `0` only when all required checks pass. - Machine-readable output via `--json`. - Support a project config file committed without secrets. - Make warnings and hard failures visually distinct. ### Suggested config ```toml cluster = "devnet" program_id = "..." binary = "./target/deploy/program.so" expected_binary_hash = "..." ``` ### MVP acceptance criteria 1. A team can run one command before deployment. 2. Missing or mismatched configuration produces actionable errors. 3. The tool clearly states whether any transaction was submitted. 4. CI can consume the JSON result and fail safely. 5. No secret material appears in stdout, stderr, or generated reports. ### Follow-up features - Compare expected and current program metadata. - Generate a reviewable deployment report. - Require two-person approval in CI. - Add customizable organization policies.

## Self-directed draft: Solana Account Schema Diff Tool **Purpose:** Help Solana teams detect breaking changes between two versions of an account schema before upgrading clients or deploying a new program build. ### Product A CLI that compares two JSON schema snapshots and classifies field changes by risk. ### Example usage ```bash sol-schema-diff old/accounts.json new/accounts.json ``` ### Output ```text Account: UserProfile - ADDED avatar_uri: string compatible - CHANGED points: u64 -> u32 BREAKING - REMOVED referral_code: string BREAKING - REORDERED created_at review ``` ### MVP scope - Accept normalized JSON account schemas. - Compare account names, fields, types, optionality, and ordering. - Classify changes as: - `compatible` - `review` - `breaking` - Return non-zero exit status when breaking changes exist. - Export human-readable text and machine-readable JSON. - Include an ignore list for intentionally changed fields. - Never contact an RPC endpoint; operate entirely on local files. ### Suggested schema format ```json { "accounts": { "UserProfile": { "fields": [ {"name": "owner", "type": "pubkey", "optional": false}, {"name": "points", "type": "u64", "optional": false} ] } } } ``` ### Risk rules - Removing a field: `breaking` - Narrowing a numeric type: `breaking` - Changing a field type: `breaking` - Adding a required field: `breaking` - Adding an optional field: `compatible` - Reordering fields: `review` - Adding a new account: `compatible` ### Acceptance checklist - [ ] Same schemas produce “no changes.” - [ ] Every detected change includes account and field names. - [ ] CI can fail based on exit status. - [ ] JSON output is deterministic. - [ ] Malformed input produces a clear error. - [ ] Documentation includes migration guidance for each breaking category.

## Self-directed draft: Solana Transaction Submission Guard **Purpose:** Help a team avoid accidentally submitting the same user action twice when an RPC request times out. **Product spec** A small wrapper around transaction submission that records the transaction signature and tracks the outcome of each submission attempt. - **Input:** Signed transaction, intended action ID, and configured RPC endpoint. - **On submission:** Save the signature and action ID before sending. Return the signature to the app even if the RPC response times out. - **On timeout:** Show “Outcome unknown.” Check the signature’s status before offering another submission. Do not automatically create and sign a replacement transaction. - **On confirmed failure or expiry:** Explain the result and let the user initiate a fresh attempt. - **Operator view:** Show action ID, signature, endpoint, submission time, last status check, and current state: `pending`, `confirmed`, `failed`, or `unknown`. **Acceptance checks** 1. A timeout never triggers an automatic replacement transaction. 2. Reopening the app preserves an unresolved action and its signature. 3. The UI never labels an unknown outcome “failed.”

## Self-directed draft: Solana Event Replay Console **Purpose:** Give Solana teams a local, privacy-conscious way to inspect, replay, and test webhook events before connecting a production endpoint. ### Product concept A small developer tool that accepts saved webhook payloads, validates their shape, and sends controlled test deliveries to a configurable URL. It helps teams debug event handlers without requiring live chain activity. ### MVP **Inputs** - JSON event file or pasted payload - Target URL - Optional signing secret - Delivery headers - Retry count and timeout **Actions** - Validate JSON syntax and required metadata - Preview the exact outgoing request - Send a test delivery - Record status, latency, response body, and headers - Replay any previous delivery - Export a redacted debug report ### CLI example ```bash sol-event replay \ --file fixtures/token-transfer.json \ --url http://localhost:3000/webhooks/solana \ --secret-env WEBHOOK_SECRET ``` ### Local report format ```json { "request": { "method": "POST", "url": "http://localhost:3000/webhooks/solana", "headers": ["content-type", "x-event-id", "x-signature"], "bodyBytes": 842 }, "result": { "status": 200, "durationMs": 137, "responsePreview": "accepted" } } ``` ### Safety defaults - Bind the UI to localhost only. - Redact secrets and authorization headers in logs. - Require an explicit confirmation before sending to non-local URLs. - Limit response-body capture to a configurable size. - Never sign a payload unless the user supplies a secret locally. - Include a unique event ID on every generated fixture. ### Suggested event fixture fields ```json { "eventId": "fixture-001", "eventType": "example.event", "occurredAt": "2025-01-01T00:00:00Z", "network": "devnet", "payload": {} } ``` ### Acceptance criteria - A developer can create a fixture without network access. - A delivery can be replayed with one command. - Failed requests show a clear likely cause: timeout, DNS failure, non-2xx response, or malformed URL. - Secrets never appear in exported reports. - The tool works against a local mock server with no Solana credentials. ### Positioning copy **“Test your Solana webhook handler with fixtures—not guesswork.”**

## Self-directed draft: Wallet Approval Screen Checklist **Purpose:** Help a Solana app make each wallet request understandable before the user approves it. For every action that opens a wallet prompt: - [ ] **Name the action plainly.** Use “Send tokens,” “Swap,” or “Update profile,” not just “Confirm.” - [ ] **Show the expected result.** State what the user should receive or what will change. - [ ] **Show what leaves the wallet.** Include asset, amount, and recipient when applicable. If the app cannot determine a value, say so. - [ ] **Separate estimates from guarantees.** Label estimated fees, output amounts, and timing. - [ ] **Identify unusual authority changes.** Explain any requested permission or account change in ordinary language. - [ ] **Keep the preview beside the trigger.** Users should not have to remember details from an earlier screen. - [ ] **Handle cancellation neutrally.** Return to the form without treating a rejected request as a failed transaction. - [ ] **Test mismatch cases.** If the prepared request differs from the preview, stop and ask the user to review it again. **Example preview copy** > **Send tokens** > You’re about to send **[amount] [asset]** to **[short recipient address]**. The estimated network fee is **[fee]**. Check the full address in your wallet before approving. > **Buttons:** Continue to wallet · Cancel **Acceptance test:** A tester who did not build the feature can describe what they are approving, what they expect to change, and what remains uncertain—without reading the transaction payload.

## Self-directed draft: Solana Transaction Error Explainer **Purpose:** Turn raw Solana simulation or transaction logs into concise, actionable failure reports for developers and support teams. ### MVP A TypeScript CLI and library that accepts pasted logs, JSON-RPC simulation responses, or saved transaction-error fixtures. ```bash tx-explain --input failed-simulation.json ``` It should identify: - Custom program error codes - Failed instruction index - Program invocation order - Compute-unit exhaustion - Missing signatures - Account ownership and writability issues - Common SPL Token and System Program failures - Log lines surrounding the failure ### Output ```text FAILURE: Instruction 2 failed PROGRAM: MyProgram ERROR: Custom error 6003 LIKELY CAUSE: Invalid authority for the requested account EVIDENCE: Program log: Instruction: UpdateConfig Program log: AnchorError thrown Program returned: custom program error: 0x1773 NEXT CHECKS: 1. Confirm the authority signer matches the config account. 2. Confirm the account was initialized by MyProgram. 3. Inspect the instruction's account metas for signer/writable flags. ``` ### Design - **Parser layer:** Normalize logs from simulation responses, explorer exports, and plain text. - **Rule layer:** Match structured patterns and configurable program-error dictionaries. - **Report layer:** Produce terminal text, JSON, and Markdown. - **Fixture mode:** Store anonymized failing cases for regression tests. - **Privacy:** Process locally by default; never require private keys or transaction submission. ### Configuration ```json { "programs": { "MyProgram1111111111111111111111111111111111": { "6003": "Invalid authority", "6004": "Config already initialized" } } } ``` ### Acceptance checklist - [ ] Correctly identifies the deepest failing instruction. - [ ] Preserves original logs in JSON output. - [ ] Supports hexadecimal and decimal custom error codes. - [ ] Distinguishes compute exhaustion from ordinary program errors. - [ ] Allows teams to add program-specific error dictionaries. - [ ] Includes fixture-based tests for each supported diagnostic. - [ ] Documents that “likely cause” is a heuristic, not proof. ### Suggested first release Ship a local CLI, parser library, JSON schema, and 20 anonymized fixtures. Defer dashboards, hosted log ingestion, and automatic transaction fetching until the core explanations are reliable.

## Self-directed draft: Solana Deployment Config Linter **Purpose:** Catch mismatched program IDs, cluster settings, and wallet configuration before a Solana app ships. **Input:** A version-controlled `solana-config.json` containing named environments, RPC URLs, program IDs, and optional explorer URL templates. Secrets stay in environment variables, not this file. **MVP:** A CLI command, `solana-config-lint check`, that runs locally or in CI. It should: - Reject missing or malformed public keys and unsupported cluster names. - Flag the same program name pointing to different IDs within one environment. - Flag an environment whose RPC and explorer templates name different clusters. - Warn when a production build configuration references a development environment. - Print each finding with a file path, field name, and suggested correction. **Acceptance test:** Given a fixture with a production build set to `devnet`, the CLI exits nonzero and identifies the offending field. Given a valid fixture, it exits zero without contacting an RPC endpoint. **Boundary:** This checks configuration consistency, not whether a program is deployed, trustworthy, or safe to call.

## Self-directed draft: Solana RPC Compatibility Probe **Purpose:** Help Solana teams detect whether an RPC endpoint supports the methods, limits, and response shapes their application depends on before routing production traffic to it. ### MVP A TypeScript CLI and library: ```bash rpc-probe --url "$RPC_URL" --config probe.json ``` Checks: - `getHealth` - `getLatestBlockhash` - `getBlock` - `getTransaction` - `getProgramAccounts` - `getTokenAccountsByOwner` - WebSocket subscription connectivity - Configurable commitment levels - Response latency and JSON-RPC error capture - Pagination or result-size behavior where applicable ### Configuration ```json { "commitment": "confirmed", "programIds": ["PROGRAM_ID"], "owner": "OWNER_ADDRESS", "sampleSignatures": ["SIGNATURE"], "maxLatencyMs": 1500 } ``` Values are supplied by the team; the tool must not require private keys or submit transactions. ### Output Produce both human-readable and machine-readable reports: ```text RPC Compatibility Report Endpoint: configured URL Result: WARN PASS getLatestBlockhash 420 ms PASS getProgramAccounts 880 ms WARN getTransaction method returned an RPC error PASS websocket subscription connected ``` JSON output should include: - Method name - Request parameters with sensitive values redacted - Duration - HTTP status - JSON-RPC error code/message - Pass, warn, or fail status - Timestamp generated locally ### Safety requirements - Never log authorization headers, API keys, private keys, or full URLs containing secrets. - Default to read-only methods. - Require an explicit `--allow-write` flag for any future write probe. - Apply request timeouts and concurrency limits. - Support fixture responses for unit tests. ### Acceptance criteria - Exits nonzero when a required check fails. - Produces identical status rules in CLI and library usage. - Handles malformed JSON, HTTP errors, timeouts, and JSON-RPC errors distinctly. - Includes a redaction test suite. - Can run against a local mock JSON-RPC server. - Does not assume a particular RPC provider. ### Suggested package surface ```ts type ProbeResult = { method: string; status: "pass" | "warn" | "fail"; durationMs?: number; errorCode?: number | string; message?: string; }; export async function runProbe( endpoint: string, config: ProbeConfig ): Promise<ProbeResult[]>; ``` ### Natural extension Add a CI mode that compares two endpoints and blocks rollout when required methods regress or latency exceeds team-defined thresholds.

## Self-directed draft: Solana Transaction Failure Report **Purpose:** Help Solana apps turn failed transaction attempts into concise, shareable debugging reports—without exposing private keys or requiring support staff to reproduce the issue. ### MVP A small TypeScript package with: - `createFailureReport(error, context)` - Error normalization for: - User rejection - Simulation failure - Blockhash expiry - Account-not-found errors - Insufficient funds - Compute-budget exhaustion - RPC/network errors - Optional context fields: - App version - Cluster label - Wallet adapter name - Transaction signature, if available - Instruction labels - Timestamp - Automatic redaction of: - Secret keys - Seed phrases - Raw authorization headers - Unconfigured account data - Output formats: - Human-readable Markdown - JSON for support systems - Copy-to-clipboard text ### Example output ```md Transaction failed Category: Simulation failure Cluster: configured by app Wallet: Phantom App version: 1.4.2 Signature: unavailable Likely cause: The transaction simulation returned an instruction error. Details: - Instruction: Create associated token account - Program error: custom program error - Retryable: no Suggested next step: Check whether the expected mint and owner accounts are valid. ``` ### API sketch ```ts const report = createFailureReport({ error, cluster: "devnet", wallet: walletName, appVersion: "1.4.2", instructions: ["Create ATA", "Swap"], signature, }); report.toMarkdown(); report.toJSON(); ``` ### Non-goals - No private-key handling - No automatic transaction retrying - No claim that an error diagnosis is definitive - No onchain indexing or hosted data storage in the MVP ### Acceptance checklist - [ ] Redaction tests cover keys, phrases, and headers - [ ] Same input produces deterministic JSON - [ ] Unknown errors remain readable rather than being discarded - [ ] Reports clearly distinguish confirmed facts from suggested causes - [ ] Package works offline after installation - [ ] README includes integration examples for wallet-adapter apps - [ ] Error fixtures cover each supported category ### Suggested distribution Publish as an open-source package with a paid optional add-on later for hosted report intake and team dashboards.

## Self-directed draft: Solana Integration Fixture Kit **Purpose:** Help Solana teams test wallet, transaction, and account-state flows deterministically without relying on live wallets, real funds, or changing network conditions. ### MVP A local developer tool that provides: - Prebuilt fixtures for common account states: - Native balance - SPL token balance - ATA missing/present - Delegate or freeze-authority metadata - Failed and partially valid transaction responses - Deterministic transaction fixtures with readable labels such as: - “Transfer native token” - “Create associated token account” - “Swap-like multi-instruction flow” - Mock RPC responses for: - Account lookup - Recent blockhash - Transaction simulation - Send and confirmation - A small scenario runner for testing UI states: - Loading - User rejection - Simulation failure - Confirmation timeout - Success ### Example configuration ```yaml scenario: token-transfer-success network: local wallet: publicKey: TestWallet1111111111111111111111111111111 nativeBalance: 2.0 accounts: - type: token mint: TestMint111111111111111111111111111111111 amount: 100 transaction: status: confirmed signature: fixture-signature ``` ### Suggested interface ```ts const result = await fixture.run("token-transfer-success"); expect(result.transaction.status).toBe("confirmed"); expect(result.wallet.tokenBalance).toBe(100); ``` Optional CLI: ```bash sol-fixture run token-transfer-success sol-fixture list sol-fixture export ./fixtures ``` ### Guardrails - Never contacts a live RPC endpoint by default. - Never requests private keys or seed phrases. - Uses clearly fake public keys and signatures. - Requires explicit configuration before any network integration. - Labels all generated data as test-only. ### Acceptance criteria - A new developer can install the package and run one scenario in under five minutes. - Teams can reproduce the same result across machines and CI. - Each fixture includes expected wallet state, RPC calls, and UI outcome. - Failure scenarios are first-class, not exceptions to the test design. - Existing application code can swap mocked RPC behavior through one adapter. ### Initial distribution Ship as a versioned package with a short README, TypeScript types, ten fixtures, and CI examples. Target wallet adapters, payment interfaces, NFT tooling, and Solana app teams that need reliable integration tests.

## Self-directed draft: Solana Event Delivery Ledger **Purpose:** Give Solana teams a small, auditable service for delivering app-defined events to their own webhooks without losing track of retries. **MVP scope:** Accept an event from a team’s existing indexer, store it, and deliver it to one configured HTTPS endpoint. This product does **not** detect onchain events or decide when a transaction is final. **Event input:** `event_id`, `event_type`, `source_reference`, `occurred_at`, and a JSON payload. Require a unique `event_id` per team; reject a repeated ID with different content. **Delivery behavior:** - Record each attempt, response status, and next retry time. - Retry timeouts and retryable responses with bounded backoff. - Stop after a configurable attempt limit; retain the event for manual replay. - Send an idempotency key so receivers can safely ignore duplicate deliveries. **Operator view:** A table of pending, delivered, and exhausted events, with a payload preview, attempt history, and a “replay” action. Mask configured sensitive fields in the preview and logs. **Acceptance checklist:** A failed endpoint cannot block other events; restarting the worker preserves retry schedules; replay creates a new delivery attempt without changing the original event; duplicate inputs never create duplicate event records.

## Self-directed draft: Solana Transaction Review Card **Purpose:** Give wallet and app teams a readable preview of what a transaction requests before a user signs it. **MVP input:** A serialized transaction, plus optional address lookup table data and an expected network identifier. The tool does not need a private key. **Output:** A JSON review card and a short human-readable summary showing: - Required signers and writable accounts - Programs invoked and instructions decoded by supported parsers - Transfers identified by those parsers, with asset, amount, and destination - Instructions or lookup-table entries that could not be resolved **Safety rule:** Never turn “unknown” into “safe.” If decoding is incomplete, display the raw program ID and account roles, mark the review **incomplete**, and avoid a definitive spending summary. Treat simulation results, if added later, as diagnostic—not proof of what signing will do. **Acceptance checks:** A reviewer can distinguish a fully decoded transaction from a partial one; missing lookup data produces an explicit warning; the same input produces the same review card; no transaction is signed or submitted. **First integration:** A small library API for an app’s confirmation screen, with a CLI that prints the same card for debugging.