Wallet age and behavior

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

A page showing “wallet age 25 days” may really mean25 days since the earliest record returned by one indexer. The account could have existed or acted earlier. A quiet chart can also reflect a missing interval rather than inactivity.

This lesson replaces vague age and behavior labels with defined observation windows, event counts and coverage-adjusted descriptions. It never turns observed age into true creation time or activity into a judgment about a person.

Define first seen precisely

First seen requires a source, query, network, target and activity rule. First signature, first successful transfer, first outbound action and first token-account event can occur at different points. Name the selected rule before reporting an age.

Solana signature queries return referenced-address history newest first with pagination [S09-SIGNATURES]. An oldest returned row is only the earliest visible record under that query. Even successful pagination does not automatically establish complete prehistory for every associated account or provider retention period.

A true account-creation claim needs a relevant mechanism and evidence. A key may exist privately before it ever appears in records; a contract deployment time concerns the contract, not the creator's key generation or a person's first wallet. A token-account creation time concerns that specific account, not necessarily its owner's existence.

Separate clocks and contexts

Ledger context, reported event time, source capture time and analysis time are different. Solana transaction responses can have null blockTime [S09-TRANSACTION]. If event time is absent, retain slot context without inventing a calendar timestamp.

The fixture supplies artificial calendar-day offsets for arithmetic. No real wall-clock observations were collected, and observedAt remains null. SIM-DAY6 is not an encoded real date. A subtraction between supplied offsets yields synthetic elapsed days only.

A span from day6 to day29 is 23 elapsed days. Counting labelled calendar endpoints would give24 date positions, a different quantity. Specify whether you measure elapsed time, count dates or define a half-open interval. Do not alternate conventions to make activity appear larger.

Publish coverage before rates

Use half-open windows such as [5,31): include day5 and exclude day31. This makes adjacent windows nonoverlapping. A gap [15,21) removes six days of supplied coverage. Do not label that gap “inactive” when the source did not observe it.

If covered intervals are stipulated complete for the selected rule, event count divided by covered days is a coverage-adjusted descriptive rate. It is not an estimate of what occurred in missing days. Dividing by the full window instead answers a different question and should be explicitly named.

A rate of 0.25 successful events per covered day means five supplied events over twenty covered days. It does not mean a transaction occurred every fourth day. Clustering within days matters, and the activity is not assumed uniform.

Choose behavior measures

Count successful events separately from attempts. Count distinct active days separately from events. Multiple transactions on one day can produce a high event count while leaving active-day count unchanged.

Define asset and direction. A receive-only record is not necessarily active initiation by the target. Referenced-address events do not prove a signature. If your behavior measure asks about initiated transactions, you need signer or sender evidence rather than simply activity involving the address.

Net balance change cannot measure trading skill. A wallet may receive allocations, make transfers or custody assets for others. This lesson uses descriptive counts only, with no profit, sophistication or strategy classifications.

Handle partial observations honestly

A first visible event inside the requested window yields a bounded statement: observed since that event in the available scope. If coverage starts after the account already had funds, even first visible funding is not complete origin evidence.

No rows in a fully verified interval might support “no matching events returned under this rule.” It still does not establish no activity on another network, mint or related account. Missing provider data supports no such interval-level absence claim.

Do not extrapolate into gaps. A wallet with no returned events during a known outage cannot be described as dormant then. A graph should draw an explicit shaded unknown region rather than a zero-height bar that resembles a measured zero.

Avoid person-level behavioral labels

“Early adopter,” “bot,” “expert trader” or “new person” require stronger definitions and evidence. Timing patterns may motivate hypotheses, but do not prove automation or identity. Equal cadence can result from scheduled application actions or indexing granularity.

The account can change its control arrangement over time. Public activity continuity does not prove the same human operated every event. Contract-mediated actions and delegated execution complicate an assumption of one manual user [S09-ETHACCOUNTS; S09-DELEGATION].

Do not rank trustworthiness by age. An older observed history establishes a longer visible period under a stated source, not honesty. A newer first-seen record establishes neither a novice user nor a malicious operator.

Write a bounded activity description

A useful report names the rule, window, gaps, first and last visible matching events, count and time convention. Then state creation and control limits explicitly.

Prefer “five successful referenced transfer events across four covered active days; prehistory and six missing days unresolved” to “an experienced active wallet.” The former is reproducible. It also lets a later reviewer recalculate after better coverage arrives.

• First seen: earliest matching event visible under a specified source/rule.
• Observed span: elapsed time between first and last supplied events.
• Covered day: day included in the dataset's verified scope.
• Active day: covered date with a matching event.
• Half-open window: includes start, excludes end.
• Descriptive rate: count divided by a stated observation denominator.

ILLUSTRATIVE — FIX-P09-05. SIM-CHAIN-A / W. SIM-DAY offsets are invented calendar-day labels. Query window[5,31), coverage complete for the listed transfer rule except gap[15,21). Pre-day5 history unavailable. Analysis cutoff day31.

Amounts are normalized units of one fictional asset. No signer fields, earlier creation record or identity evidence is supplied. Rule for successful activity includes either direction, excluding failed attempts.

OBSERVED in fixture: Matching success records occur on days 6,10,22,29; day12 is a failed attempt; six days lack coverage.

INFERRED: Five successes over four active covered days; first-to-last elapsed span 23 days;25 days since first visible success at analysis day31.

UNKNOWN: True creation time, activity before day5/in the gap, initiation/signers and human continuity.

INSUFFICIENT EVIDENCE: Observed age 25 cannot be reported as actual account creation age. Missing interval cannot establish inactivity; event frequency cannot prove expertise or automation.

Treating oldest page record as creation; using null time as zero; counting both elapsed and inclusive days interchangeably; turning source outages into zero activity; and assigning skill or identity from cadence.

Calculate full window length, missing and covered days, successful event and active-day counts, covered-day rate and elapsed span. Rewrite “W was created25 days ago and stayed inactive for six days.”

• Name first-seen source and activity rule.
• Separate successful events from attempts/initiations.
• Use explicit interval conventions.
• Publish gaps before rates.
• Keep null calendar time unknown.
• Avoid creation, skill or person labels from observed age.

Wallet age is often an observation interval. Behavior statistics are useful when their event rule and coverage denominator remain visible.

First seen is not creation. No data is not no activity. A cadence describes supplied events, not a person's identity or skill.

Timeline[5,31) with gap[15,21) hatched UNKNOWN, event/attempt markers and doubled day10 events. Show26 total/6 missing/20 covered; first 6,last29,analysis31 as distinct markers. Never label first-seen as creation.

Illustrative observed activity; synthetic days are not ledger timestamps.

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.
• Ethereum accounts — Account/interface distinction and account types. Checked 2026-09-30.
• EIP-7702 Set Code for EOAs — EOA code delegation; code presence alone is not a universal EOA classification rule. 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-L06 after the worked exercise and question review.