An execution-first information architecture built around decisions, actions, and daily prioritization.
Aletheia Layer extension
This module watches public blockchain wallet addresses for large movements, dormant reactivations, repeated sequences, and contract waves. It does not track people, build trader profiles, or create copy-trading prompts. Its only job is to turn verified behavior patterns into rule-based tasks that Aletheia can rank and route.
Monitored behaviors
Large movement shift
Monitor: Track transfers, deposits, withdrawals, and bridge events that clear both a minimum size floor and a multiple of the same address's recent baseline.
Classify: Classify as a size shift when the move is materially larger than the address's trailing 30-day median movement.
Surface: Only keep it if the move touches a tracked protocol, claim route, bridge, or maintenance workflow with a plausible next step.
Dormant wallet reactivation
Monitor: Watch for an address that was inactive for at least 30 days and then resumes activity on a tracked chain or contract.
Classify: Classify as reactivation when the first new action is followed by a second confirming action inside the freshness window.
Surface: Use it to trigger review, eligibility, or maintenance tasks only. Never infer identity or intent.
Repeated sequence pattern
Monitor: Watch for the same address repeating a 2 to 4 step path such as approve, bridge, deposit, claim, migrate, or unstake.
Classify: Classify as a repeated loop when the same ordered sequence happens at least twice in 14 days.
Surface: Promote only when the repeated loop points to a reusable action or playbook the user can execute now.
Clustered contract wave
Monitor: Watch for three or more monitored public addresses interacting with the same contract or workflow inside a short time window.
Classify: Classify as a wave when the addresses repeat the same event family inside six hours.
Surface: Treat it as a stronger signal than a one-off event, but only when the user's focus universe overlaps the same protocol or chain.
Maintenance and exit behavior
Monitor: Watch for approvals, withdrawals, rollovers, migrations, renewals, revocations, and claim-then-exit sequences around the same protocol.
Classify: Classify as maintenance pressure when the sequence implies upkeep, migration, or contract-risk review rather than market speculation.
Surface: Generate maintenance, review, or claim tasks. Do not create buy, sell, or copy-trade actions.
Detection and Classification Rules
Behavior detection stays rule-based: normalize raw events, compare them with a recent baseline, and only classify the patterns that can be named clearly.
If
a raw transaction touches a transfer, bridge, deposit, withdraw, claim, approve, mint, stake, unstake, revoke, or migrate event
Then
normalize it into a standard event type before pattern detection.
If
an event clears both the configured minimum size floor and at least 3x the same address's trailing 30-day median movement
Then
classify it as a large movement candidate.
If
an address has no qualifying activity for 30 days or more and then emits a tracked event
Then
classify the first event as dormant reactivation candidate.
If
the same address repeats the same ordered 2 to 4 step event path twice inside 14 days, or three or more addresses repeat it inside six hours
Then
classify it as a repeated sequence or clustered wave.
If
a detected pattern does not map to a protocol, contract, chain, or action window that can be named clearly
Then
keep it as monitor-only and do not surface it as a signal.
Aletheia Promotion Rules
A wallet behavior trend only becomes a surfaced signal when it survives the same action-first standards as the rest of Aletheia.
If
a classified wallet pattern points to a verb-first next step with a visible on-chain source and a real consequence for delay
Then
promote it into the Aletheia action pipeline.
If
the pattern overlaps the user's configured focus area, active wallet state, or a tracked protocol playbook
Then
treat it as eligible for surfacing.
If
the pattern is only interesting, unusual, or large but does not change what the user should do next
Then
filter it out as noise.
If
the same pattern for the same contract, chain, and action window is already active
Then
merge into the existing signal instead of creating a second one.
If
surfacing the signal would require inferring wallet owner identity, ranking people, or encouraging imitation of another address
Then
suppress it completely.
Urgency and Priority Rules
Urgency comes from consequence and time pressure. Priority rises when the pattern repeats or confirms itself.
If
the pattern implies a hard deadline, forced maintenance, security review, lockout risk, or claim window that can close before the next review cycle
Then
assign High urgency.
If
the pattern implies a useful review or maintenance action that should happen today but is not yet irreversible
Then
assign Medium urgency.
If
the pattern is relevant and action-ready but remains open-ended for several days with little downside
Then
assign Low urgency.
If
the same pattern is confirmed by multiple addresses in six hours, or by a second confirming step from the same address
Then
raise priority one level inside its urgency band.
If
the signal is older than 24 hours without follow-through, or it is still based on a single isolated event
Then
lower priority or suppress it until new evidence arrives.
Daily Execution Board Routing Rules
The Board only receives wallet behavior signals that already resolve into a concrete same-day task.
If
a wallet behavior signal is High urgency and already names a concrete task
Then
create a Daily Execution Board card immediately in the must-act-now queue.
If
a wallet behavior signal is Medium urgency with a same-day review or maintenance task
Then
create a Daily Execution Board card for today's queue.
If
a wallet behavior signal is Low urgency or lacks same-day pressure
Then
send it to Opportunity Feed instead of the Daily Execution Board.
If
a Board task is created from wallet behavior
Then
store a verb-first title, why-now sentence, on-chain evidence, freshness limit, and one recommended action.
If
the underlying on-chain condition resolves, expires, or fails verification
Then
close, ignore, or archive the Board task automatically.
Action Templates
Wallet behavior trends do not surface as dashboards. They convert into a short set of review, claim, eligibility, maintenance, or security tasks.
Review protocol maintenance window
Pattern: Clustered approvals, withdrawals, migrations, or renewals around a contract inside the user's focus universe.
Routing: Send straight to the Daily Execution Board when the window closes before the next review cycle.
Check claim or eligibility route
Pattern: Dormant reactivation or repeated claim interactions around a live claim, mint, or unlock contract.
Routing: Board if the claim window is short; otherwise Opportunity Feed with a freshness timer.
Verify bridge or migration exposure
Pattern: Large movement or clustered bridge behavior into a tracked chain or migration path used by the user's active positions.
Routing: Board when it implies an immediate review; suppress if it is only observational.
Review contract approval exposure
Pattern: Repeated approve or revoke behavior that suggests permission cleanup or security review.
Routing: Board when the user has matching exposure; otherwise keep it out of the surfaced queue.