Transaction history

EN source master · P09-L02 · 45 minutes estimated · needs_review

A transaction page can show a transfer, its instruction, a decoded summary and a balance change. These can be several views of one event. Adding every line inflates activity, while ignoring execution status can turn failed attempts into successful transfers.

This lesson teaches a history ledger with event identity, success, nested activity and fees separated. It prepares the funding analysis without assuming that every address reference means a payment.

Define history coverage

Write network, target address, related token accounts, requested window and collection method. Solana getSignaturesForAddress returns signatures referencing the requested address in accountKeys, newest first, with pagination parameters [S09-SIGNATURES]. A returned page is a discovery list, not a complete transfer ledger.

A referenced address need not be a signer or recipient. Instructions can reference programs, data accounts and read-only state. Inspect the record's role before counting involvement as action. Querying an owner address may also fail to discover every operation involving separate token accounts; inspect the intended coverage rather than declaring full history.

Deduplicate signatures across overlapping pages, but preserve different instructions within the same transaction. Sorting must respect available slot/block order and any intra-context ordering evidence. An interface's displayed order is not automatically exact execution order.

Verify the result before counting effects

Retrieve execution metadata for discovered records. Solana getTransaction can return null at the requested commitment and has nullable time or metadata fields [S09-TRANSACTION]. Treat missing retrieval as unresolved, not as a failed or nonexistent event.

A confirmed/included record can still contain a failed operation. Record success separately from finality. A submitted amount describes intent; a successful balance effect describes execution. For the fixture's failed T2, token transfer effects are explicitly zero while the supplied native fee remains charged.

Do not universalize simplified rollback statements to every chain feature. The exercise excludes authorization changes and other non-transfer mechanisms. Its result table supplies the relevant effects directly. In real analysis inspect actual protocol rules and state differences.

Separate event identity from display rows

Choose an event key: network, transaction signature/hash and instruction path or log index, as applicable. A transfer instruction, its decoded summary and the matching balance delta may corroborate one event. They are not three separate transfers.

A balance delta is a net result. If an account sends 10 and receives 4 in one window, the delta is−6 while gross outflow is 10. The delta does not erase the incoming transfer, and summing gross movement with net delta double-counts.

Nested calls need their own semantics. Geth's callTracer describes call frames, with configurable scope [S09-TRACES]. An internal call is part of a parent transaction, not a separately signed transaction. Some frames carry native value; other calls carry zero and execute code. Do not count every call as a payment.

Distinguish calls, logs and token movements

An EVM receipt supplies transaction linkage, status and logs [S09-RECEIPT]. A token event log and a native-value call are different records. The token contract emitting a Transfer log is not necessarily the economic recipient.

On Solana, result metadata distinguishes instructions, inner instructions, fees and balances [S09-STRUCTURES]. An inner instruction can identify a mechanism inside a parent operation. A summary of that same instruction should use the same event locator.

A contract call with a token-transfer log can be one economic token movement plus a call relationship, rather than two token movements. Preserve both observations in typed tables, then choose the counting unit appropriate to the question.

Keep fees separate

Fees use the network's native asset and have a specific payer. They are not target-token transfers. Solana documentation describes a native transaction-fee mechanism [S09-FEES]. Do not assume every visible address paid the fee or every failed attempt was free.

Fee totals should count once per supplied transaction result, not once per instruction or summary line. Convert raw fee units using the native precision if the real dataset supplies it. This exercise provides normalized fictional fee units and no price conversion.

Reconcile token movement and native costs separately. A token delta can be correct while the native balance has additional rent, deposits or unrelated effects. The fixture explicitly excludes those effects; real records require additional reconciliation.

Build a bounded history table

Use columns for event locator, object role, result, asset, direction, gross amount, fee payer and uncertainty. Maintain a separate unresolved-record list. Do not delete missing records just to make the visible success count look complete.

A count of successful token-transfer transactions differs from a count of token-transfer events. One transaction may have multiple events. State which statistic you report. A failed attempt can belong in an attempt count while contributing zero to successful movement.

The final description should name the observation window and supplied coverage. History teaches what occurred in available records, not why an actor chose it. A successful transfer is neither proof of affiliation nor a price signal.

• Execution result: success/failure of the inspected operation.
• Event locator: transaction plus instruction/log path.
• Call frame: nested execution within a transaction.
• Gross flow: sum of directional movements.
• Net delta: final minus initial balance.
• Fee payer: account bearing the supplied native cost.

ILLUSTRATIVE — FIX-P09-02. SIM-SOL-A / W / MINT-T. Complete effects for T1–T3 only, synthetic ordered S1,S2,S3. Native fees are normalized and paid by W. No other window effects. Initial token balance 100.

Separate SIM-EVM-A example E1 succeeds with top-level W-E→ROUTER value0; nested ROUTER→C-E native value2 and one token Transfer log for7 units from W-E to C-E. The fixture stipulates distinct assets/effects and complete call coverage. No fee value is supplied for E1.

OBSERVED in fixture: T1's three views describe one10-token transfer; T2 fails; T3 receives 4. E1 contains a zero-value call, a 2-native movement and a 7-token log.

INFERRED: Successful target outflow 10, inflow 4, net−6; ending 94. T1–T3 native fees total 0.04.

UNKNOWN: Earlier history, human operators, E1 fees and motives.

INSUFFICIENT EVIDENCE: H2/H3 cannot add20 extra transferred tokens. T2's attempt cannot count as a successful 20-token outflow. E1's nested call is not a second independently signed transaction.

Adding summaries and deltas to transfers; equating inclusion with success; treating every address reference as action; mixing native fees with token amounts; and dropping unavailable records from a coverage claim.

Build a deduplicated token ledger for T1–T3. Compute gross and net flow, ending balance and fees. Classify E1's call and asset movements, with no total across different assets.

• Record discovery and history coverage.
• Verify execution result separately from finality.
• Key events by transaction and path.
• Reconcile gross flow and net balance.
• Count fees once and preserve payer/asset.
• Keep calls, logs and human attribution distinct.

History reconstruction is event accounting, not line counting. Successful movements, failed attempts and fees answer different questions.

Several views can describe one transfer. Nested calls are not separately signed transactions. Missing records remain unresolved rather than absent.

Timeline T1–T3 with H1/H2/H3 bundled as one event, T2 failed with fee still supplied, T3 incoming4. Show flow10/4/net−6/ending 94 and separate fee 0.04 panel. Separate E1 call tree from token/native amount rows.

Illustrative event accounting; rows and nested calls are not independent transactions.

Use deterministic SVG/HTML or charts with units, evidence locators and text alternatives. Navy/black with restrained cyan, electric blue and violet; no decorative or fabricated explorer screenshots. At 390px stack annotations; verify 768px, desktop and Arabic RTL when assets are implemented. Keep identifiers LTR and factual time/edge/axis directions unchanged. Use only the official supplied ZECOIN mark. Both visual records remain specifications.

WALLET_INTELLIGENCE maps to read-only inspection of public address records, relationships and provenance. Verify supported network, exact identifiers, fields and coverage before any runtime integration; no live provider capability is claimed here. Use the embedded offline exercise if data or paid access is unavailable. No wallet connection, credentials, private key, signature or live trade is required. Missing data stays unknown. Academy progress, creator status, payments and referrals never alter Radar evidence.

• Solana getSignaturesForAddress — Referenced-address signature history, newest-first order and pagination. Checked 2026-09-30.
• Solana getTransaction — Transaction lookup, commitment and nullable data/time fields. Checked 2026-09-30.
• Solana RPC JSON Structures — Result metadata, fee, instructions and balances as distinct views. Checked 2026-09-30.
• Solana Fees — Native transaction fee mechanism; not a token movement or universal cost model. Checked 2026-09-30.
• Geth Built-in Tracers — Call-frame trace scope and tracer-specific configuration. Checked 2026-09-30.
• Ethereum Execution APIs eth_getTransactionReceipt — Receipt status, transaction linkage and logs. Checked 2026-09-30.

All example records are original ILLUSTRATIVE fixtures, not historical/live chain measurements. Documentation explains mechanisms, not invented amounts or labels. Synthetic chronology is explicitly bounded; observedAt=null is intentional. OBSERVED in an exercise means a supplied fixture record. Re-review documentation and deployed decoding before publication. Provider labels do not establish identity; address control and human attribution require distinct evidence.

P09-L03 after the worked exercise and question review.