LAB NOTE 001 FROM THE FAILURE ARCHIVE
GHOSTLOG gives failed Solana transactions an afterlife: a sourced record, a readable explanation and a report someone else can inspect. Its community token represents the people and culture forming around that work.
01 THE PROBLEM IN PLAIN LANGUAGE
A failed transaction should leave more than an unexplained error.
A wallet can say that a transaction failed without explaining much more. A signature leads to technical records, but an error number alone rarely tells a person where to look next. The transaction’s intention, execution result, logs and fee are related pieces of information, not interchangeable descriptions of what happened.
A local program may report success before a later instruction fails. A custom code can mean different things in different programs. Some providers omit metadata or return no confirmed record at all. Presenting these situations as the same failure would make a polished interface less useful than the raw evidence.
GHOSTLOG starts with the returned record and keeps its limits visible. It separates the recorded outcome from a supported interpretation and from information that remains unknown. The goal is to help a person inspect a specific event, rather than promise a universal answer for every application on Solana.
A failed transaction can leave useful experience. Understanding it should not require owning a token.
02 WHAT GHOSTLOG IS
GHOSTLOG is a ghost token project built around a real read-only transaction tool. The product turns available execution evidence into readable records. The community identity grows around those records, the ghost character and the practice of leaving better clues for the next person.
A case can help someone describe a failed swap to a developer, distinguish a network fee from an intended payment, or preserve the exact error and rule version used in an explanation. A report is useful because its transaction and evidence can be checked, not because its character looks certain.
The first release supports user-initiated lookups, local history, curated historical cases and PNG or JSON exports. It does not automatically collect every failure on the network. Local notes remain in the current browser, and the public case collection changes through maintainer review and a new project release.
WHY CALL A RECORD A GHOST
A ghost is the narrative form of a sourced failure record. It has a transaction identity and the traces that survived the failed attempt. Calling it a ghost gives the archive a character without changing what the underlying record proves.
A newly reviewed case can reveal a missing rule or a better explanation. That improvement requires an explicit code change and verification. Collecting a record does not automatically train a model, issue a token, mint an NFT, pay a reward or create an economic right.
03 WHAT A FAILURE RECORD CONTAINS
TRANSACTION IDENTITY
The transaction signature identifies the record being inspected. Supported explorer links are parsed to extract that signature; the application does not fetch arbitrary user-supplied URLs. The source, network and retrieval time stay attached to the case so another reader can distinguish a historical snapshot from a new lookup.
OUTCOME
The final transaction outcome comes from transaction metadata. A null error means success only when the required metadata exists. A non-null error confirms a failure. Missing metadata, an unavailable record, an unsupported version and a provider error have their own states and do not become confirmed failures.
EXECUTION PATH
The normalizer combines static account keys with returned lookup-table addresses and preserves recorded instruction indexes. Inner calls are shown only to the extent that the metadata supports them. A gap in the record stays a gap; the interface does not invent a complete execution tree to make a diagram look finished.
FEES AND BALANCES
The network fee is read from the record’s fee field. Balance changes are separate observations and may involve several assets and accounts. Raw integer amounts remain strings until exact arithmetic is needed, and token decimals are applied explicitly. Missing fee or balance data is unavailable, never an invented zero.
EVIDENCE AND RULES
An explanation names its evidence level and rule version. Custom program errors are matched to the identified originating program, not translated from a number alone. A supported interpretation can be inspected alongside the raw error and available logs; an unrecognized error retains its original form.
EXPORT BOUNDARY
A Ghost Report carries the public transaction identity, result, program, network fee, evidence references and diagnosis version. Its export fields are explicitly selected. Private local notes, browsing history and provider credentials are excluded. The PNG is for reading; the JSON keeps structured details and exact integer values.
04 ONE RECORD FROM START TO FINISH
The instrument at the top maps the code. It is an interactive explanation of the architecture, not live telemetry.
First, the user provides a transaction signature or a supported explorer link. Input validation checks the signature encoding and rejects unrelated links. The user can also open a historical case that ships with the project or a record already saved in this browser.
Second, the query layer reads the public transaction record at confirmed commitment. A newer request cancels or supersedes an older one. This prevents an earlier response from appearing under a different signature after the user changes the input.
Third, the returned transaction is normalized without discarding integer precision. Its version, metadata, account keys, instructions, logs, resource information and balances are checked for availability. An unsupported response remains separate from a failed transaction.
Fourth, the final result is determined from the metadata. Local log messages are kept as evidence but cannot overrule that result. The path can show an earlier instruction executing while still making clear that the whole transaction ultimately failed.
Fifth, supported rules interpret the error when its program context and available evidence are sufficient. The explanation identifies the rule and its source. Otherwise the report says that failure is confirmed but its specific cause is not classified.
Sixth, the record can be kept in the browser with a private note. Historical cases supplied by maintainers remain distinguishable from personal query history. Deleting a local record removes that browser copy; it does not change the public blockchain.
Finally, the user exports a readable PNG or structured JSON report. The report preserves the evidence boundary and source information. Sharing it is a separate user action; the application does not automatically publish the query, upload personal notes or send a message to anyone.
05 WHERE SOLANA FITS
The chain supplies the record. The explanation must stay within it.
Solana provides the public transaction identity and the execution metadata returned by an RPC provider. The tool reads those records. It does not deploy a diagnostic program to the chain or need a wallet signature to explain an existing transaction.
The returned account indexes and instruction structure determine what can be associated with a program. Logs can add context, but missing or truncated logs limit attribution. The implementation keeps final result classification independent from those explanatory details.
Public transaction records and private annotations have different boundaries. The chain record is already public. A note written in the archive is browser-local and excluded from the standard export. Changing browsers or clearing browser storage can remove that local history.
Public RPC services can rate-limit requests, time out or lack an older record. These are data availability conditions. They are not evidence that the requested transaction failed. A retry reads the record again; it does not repeat the original onchain operation.
06 THE CORE MODULES
INPUT
The input parser recognizes a base58 transaction signature and a limited set of explorer transaction links. It checks the decoded length before querying. The same signature is used for the request, displayed report and evidence link so the record identity does not silently drift.
OUTCOME
The query layer uses the public getTransaction method and keeps cancellation and response validation close to the request. Provider failures become explicit lookup states. The browser can still open bundled historical records when a network lookup is unavailable.
NORMALIZER
The normalizer produces a consistent record from the returned transaction data. It preserves missing values, supports the implemented transaction versions and assembles account keys in their recorded order. It does not fill metadata gaps with plausible-looking values.
DIAGNOSIS
The rule set contains bounded interpretations for known runtime errors, the System Program, the standard Token Program and selected Jupiter Swap errors. The same evidence and rule version produce the same diagnosis. Program upgrades and unmapped errors remain reasons to inspect the source and raw record.
ARCHIVE
The archive stores user-selected records in the current browser and offers local notes, search and removal. Curated cases are separately labeled snapshots. Neither type of record implies a global contribution network, a cloud backup or automatic review by the project.
REPORT
The exporter builds a PNG and a structured JSON document from a field whitelist. It includes the transaction link and rule version so a report can be revisited. A successful download means the file was prepared; it does not certify that an interpretation covers every cause of the failure.
07 WHAT EXISTS TODAY
The local project contains the React transaction inspector, query and normalization layers, deterministic rules, browser archive, report exporter and historical record snapshots. The code viewer on this page is generated from those files, so its examples correspond to the implementation rather than a different protocol.
Each module beneath the instrument opens the relevant source file and a matching symbol. The file tree, line numbers, copying and downloading work with the embedded source snapshot. This helps readers follow a claim from the project description to the specific code responsible for it.
Local builds and tests are different from a production deployment. This page does not claim that a token has launched, a program has been audited or a network service runs continuously. The token's issuance information remains unannounced until it is provided and verified.
08 THE SECURITY BOUNDARY
An interpretation is limited by the record, the RPC provider and the supported rule set. An error can be real without its ultimate cause being known. The application does not claim to reconstruct private quotes, missing application state or every intermediate decision made before the transaction was submitted.
Program-specific codes require program-specific context. A code that means one thing in the standard Token Program may mean something else in another program. When the available execution evidence does not establish the origin safely, GHOSTLOG keeps the cause unclassified.
A failed transaction can still have a network fee. Special cases such as durable nonce advancement mean it is also unsafe to promise that every state change except the fee always disappears. Reports present recorded balances and metadata separately from general explanations of transaction behavior.
The tool never signs, broadcasts or automatically retries a transaction. It does not choose a new slippage tolerance, trade assets or promise fee recovery. The next action belongs to the user and the application responsible for the original operation.
09 WHAT THE TOKEN REPRESENTS
The project token represents community identity and culture around GHOSTLOG, its ghosts and useful failure records. The tool works independently of token ownership, and contributions can come from anyone who can provide relevant, checkable evidence.
No service-payment requirement, staking yield, revenue share, buyback or governance right is defined for the first release. A case does not create a reward obligation. The official X account is linked in the header. The token symbol and contract address remain unannounced until the project supplies confirmed information.
If batch services or ongoing monitoring are actually introduced later, their operation and any relationship to a token need their own design and disclosure. They are not current features, and this project description does not promise future economic value capture.
10 THE DIRECTION
The next useful improvements are more reviewed cases, better source-backed explanations and broader tested program coverage. A proposed rule should include the relevant program context, a real example and tests that protect against a misleading diagnosis.
A maintained archive can grow through release-by-release review. That work may include clearer evidence links, more robust handling of incomplete records and better reports for developers and support teams. It does not require claiming that every new query automatically teaches the system.
The long-term purpose stays close to the first useful case: read what failed, explain only what can be supported, preserve the record and help the next person find a clue. GHOSTLOG is the community that forms around giving those failed transactions something useful to leave behind.
SOLANAEVIDENCEREAD-ONLYGHOST REPORTSCOMMUNITY TOKEN
GHOSTLOG project note 001 / sourced records, explicit limits / October 2026
