A reconciled, complete window contains zero valid inputs.
A circuit shaped by its own market.
On-chain activity becomes signals.
Signals move through components.
Each cycle leaves a trace.
Local example inputs. No transactions are submitted.
Input timeline.
No target mint or observation accounts are configured.
Six bounded responsibilities.
Recent circuit records.
CIRVYK Core
Six processing components. One explicit route. Inspect the mechanism at every stage.
Signals, in context.
One shared reader. Inspect the selected window, its inputs and the actual processing result.
Observed events.
| US Eastern | Type | Source / signature | Slot | Path |
|---|
An address match means the parser observed that address in the transaction's account list. It does not establish beneficial ownership, a buyer or a seller.
Assemble a reproducible window.
Configure example inputs. Inspect every stage. No remote deployment or transaction.
A record of the route.
Window inputs, baseline evidence and the rules that shaped each path.
A market becomes a circuit.
CIRVYK turns a defined slice of token activity into bounded inputs, visible processing paths and replayable records. V1.1 restores the instrument around the V1 six-stage engine; it does not introduce a new consensus system or trading strategy.
The engine is a pure function of inputs, observation scope, epoch-aligned window, baseline and rules. Every page reads the same selected context. The Source workspace publishes the actual browser modules, configuration and documentation in an explicit public file set.
| Interface | Purpose | Primary inspection |
|---|---|---|
| Home | System overview | Core view, relative activity, Eastern time grid, waveforms and recent records |
| Live | Scoped observation | Time / type / public-address filters and retained event evidence |
| Core | Physical route & topology | Component rack, input/output detail, selection and path replay |
| Memory | Browser-local records | Timeline, complete Trace detail, JSON import/export and PNG Snapshot |
| Source | Actual public implementation | File tree, code lines, file switching, highlighting and copy |
| Workbench | Local signal laboratory | Reproducible parameters, chassis, waveform and six-stage execution |
| Protocol | Technical reference | Rules, formats, examples and observation boundaries |
One transaction, at most one Pulse.
A Pulse is a supported input admitted by the parser and the engine. A Trace describes one fixed processing window. A Snapshot is a PNG exported from a Trace. Multiple instructions in the same transaction do not multiply its Pulse count for the same target mint.
01 Sensor normalize bounded inputs; preserve source and epoch timestamps 02 Resistor verify eligibility; deduplicate; retain rejection reasons 03 Capacitor accumulate accepted inputs inside [start, end) 04 Comparator inspect the five preceding consecutive complete windows 05 Switch select QUIET, FLOW or SURGE only for a final window 06 Memory prepare the reproducible record for local persistence
Live inputs deduplicate by signature + mint; local fixtures deduplicate by input ID. Eligibility checks include time, source mode, parser verification, supported kind and scope. This is bounded filtering, not a complete anti-sybil or wash-trading detector.
The detailed SVG contains display structure as well as six interactive processing components. Passive traces, rails and framing are graphic topology. They do not claim independent online workers or additional processing stages.
Three paths. No hidden score.
The window contains valid inputs and does not meet the enhancement rule.
At least 10 valid inputs and at least twice the mean of the preceding five complete consecutive windows.
Live observation uses 60-second epoch-aligned windows. Displayed times use US Eastern time (America/New_York), with automatic EDT/EST daylight-saving transitions. The start is inclusive and the end is exclusive. A baseline window must have the same scope and full rule configuration, be final, have complete coverage and complete parsing, and occupy its exact preceding position. A gap or conflicting count stops the consecutive baseline.
| Engine state | Condition | Visible conclusion |
|---|---|---|
| accumulating | The current time is before window.end | Accepted inputs may accumulate; path remains null |
| incomplete | The window ended but coverage, parsing or live scope is incomplete | No final path, including no QUIET conclusion |
| final | Ended window + complete coverage + complete parsing + configured scope | Apply QUIET / FLOW / SURGE rules |
| Baseline unavailable | Fewer than five consecutive complete preceding windows | No baseline average or growth ratio; non-empty final window is FLOW |
| Baseline average = 0 | All five qualifying baseline counts are zero | No finite growth ratio; the count threshold still applies to route selection |
Selecting a smaller time range filters the visible inputs and instruments. It does not recompute the whole-window route or invent a new baseline. The local Workbench can use 60, 120 or 300 seconds; this changes only its example Trace, not the live rule.
Read the actual rule configuration and engine
Loading this build's source…
Evidence travels with the trace.
The current record schema is circuit.trace.v1. These are actual fields returned by finalizeWindow(). Stored timestamps remain integer epoch milliseconds; the interface displays US Eastern time. Raw machine data and ISO strings retain their original instant; a missing derived value is null rather than a fabricated measurement.
| Field | Shape / meaning |
|---|---|
schema | Record format identifier: circuit.trace.v1 |
id | Deterministic identity from scope, aligned start and full rules; an identity aid, not a cryptographic proof |
window | { start, end, durationMs }; the processing interval [start, end) |
observedAt | Time passed to the engine for this record; not necessarily an input transaction time |
source | { mode, label, network, mint, accounts, scopeId }; mode is live or example |
rulesVersion | The rule version attached to this record |
rules | { version, windowMs, baselineWindows, surgeMinInputs, surgeMultiplier, supportedKinds } |
inputs | Normalized, deterministically sorted bounded input list |
validInputs | Inputs admitted after eligibility checks and deduplication |
filtered | Rejected entries as { input, reason }, including duplicate decisions |
count | Number of accepted inputs; equals validInputs.length |
coverage | complete, partial or missing for the processing record |
parsingComplete | Whether parsing is complete for the supplied observation range |
baselineEvidence | Qualifying preceding records: id, window, source, rulesVersion, count, status, coverage and parsingComplete |
baselineReady | True only when all five required preceding windows qualify |
baselineAverage | Mean accepted count across the qualifying baseline, or null |
baselineReason | Explanation of baseline availability and comparison |
growthRatio | count / baselineAverage for a final record with a positive complete baseline; otherwise null |
path | QUIET, FLOW, SURGE or null |
status | accumulating, incomplete or final |
reason | Pending-state explanation, or null for a final record |
progress | Elapsed fraction of the window, bounded to [0, 1] |
steps | Six records with id, name, label, inputCount, outputCount, status and detail |
Input fields are limited to id, signature, mint, slot, timestamp, kind, source, address, accounts, verified, scopeId. The live reader emits Activity or Transfer when supported evidence is available. Local fixtures have no transaction signatures.
Memory is local to this browser: at most 30 records and 3 MB. The newest windows are retained first; an updated record replaces the same fixed-window ID. JSON exports contain the inputs, baseline evidence and rule configuration. Import validates the data shape, reruns the actual engine, and compares every derived field before saving.
An imported file can declare live provenance, but that declaration is not a fresh chain verification. Imported historical records stay outside locally observed live counts and use historical labeling. A Snapshot is a downloadable PNG, not a public record link, a permanent shared memory or an on-chain write.
Observed does not mean everything.
The read-only Solana adapter queries explicitly configured accounts or pools, then examines finalized transactions for target-mint token balance changes or supported parsed SPL Token operations. A mint address alone does not index all token activity. Plain transfers are never relabeled as buys or sells, and an account-list match does not establish beneficial ownership.
| Reader / coverage state | Meaning | What the instrument does |
|---|---|---|
| unconfigured / invalid_configuration | A required scope value is absent or invalid | Show configuration scope; local examples and saved replay remain usable |
| ready / checking | Configuration loaded / one shared request in progress | Retain source labels, previous values and their timestamps |
| live + complete | Account scan, finalized timestamp boundary and transaction parsing reconciled | Finalize only ended windows fully inside the proven interval |
| live + partial | Bounded pagination, pending parsing or only part of the range is proven | Expose retained inputs and unresolved reasons; do not infer empty coverage |
| unavailable / error / rate_limited | A valid range cannot currently be established | Keep the previous successful inputs and actual timestamps; allow another check |
| cursor_expired | The bounded server cursor expired or changed scope | Restart once without that cursor; deduplicate the returned evidence |
Only [reconciledFrom, reconciledUntil) is a proven range. Finalized slot and block time establish its upper boundary. Unresolved transactions constrain that boundary. Pagination limits and retention cutoffs cannot be presented as an exhaustive token history.
All seven pages share one reader. It checks approximately every 15 seconds while the page is open and visible; hidden-page polling pauses. Limits are four observed accounts, three pages of 50 signatures per account, 150 transactions per check, concurrency three and at most two retries. Cursor storage is bounded to 100 entries with a 30-minute lifetime. The interface keeps at most 4,000 retained input records by default.
A connected wallet supplies a public-address filter over observed account relationships. It requests no signature, approval, transaction or custody. Pasting a public address provides the same filtering purpose.
One selection, across the panels.
- Choose a context. The shared context strip identifies local example, live scope or historical replay, with its actual window in US Eastern time. Load example opens an explicit fixture. Live scope exits replay and returns to the scoped reader.
- Inspect a component. Hover to preview, click to retain the selection. The circuit, relative activity display and inspector use the same selected stage. Drag or zoom the circuit; Reset view restores its framing.
- Select a time range. Each activity-grid cell has an explicit Eastern time interval and accepted count. Selecting a cell narrows the related input list and highlights the same waveform bins. Unknown coverage is not colored as a proven zero.
- Inspect an event. Open its input evidence and filter reason, then locate its processing path. Accepted final inputs pass through six stages; rejected inputs stop at the filter. An incomplete window can inspect accumulation but cannot replay a concluded route.
- Replay a saved Trace. Choose it in Memory. The selected context and related instruments switch to that record and retain the historical timestamp. Playback does not add live events.
- Recover the full view. Clear filters removes time, event and component filters. Live scope leaves replay; Home returns to the overview. Resetting the circuit view changes only framing, not data or counts.
Local Workbench procedure
Choose Single pulse, Short burst or Gradual flow. Set a 60-, 120- or 300-second example window and one to five input batches. The default batch contains respectively 1, 12 or 6 inputs; the maximum is 60 inputs. Each example carries five fixed preceding baseline windows with three accepted inputs each.
Parameter changes rebuild the example Trace, chassis readouts, waveform and output through the same engine. Execute local inputs advances the six stages; Pause retains the current step, Step inspects one stage, and Reset rewinds playback while retaining the selected parameters. Automatic or manual mode changes how the path advances. Speed choices of 0.5×, 1×, 2× and 4× affect playback timing only.
The Workbench is browser-local. Its restored chassis is a display model. No remote worker is registered, no CPU capacity is rented, no token is burned and no transaction is sent.
Twelve inputs, one inspectable route.
Use Short burst, a 60-second window and one batch in the Workbench. The fixture covers 2026-10-15 20:05:00–20:06:00 EDT (UTC-04:00). All 12 local Activity inputs occur inside the window, have unique IDs, and carry example provenance without signatures.
| Stage | Actual example operation | Output |
|---|---|---|
| 01 Sensor | Normalize and order the 12 supplied fixture inputs | 12 received inputs |
| 02 Resistor | Check time, supported kind, verified flag, example scope and unique IDs | 12 accepted / 0 filtered |
| 03 Capacitor | Count accepted inputs in the aligned 60-second interval | count = 12 |
| 04 Comparator | Read preceding complete counts [3, 3, 3, 3, 3] | average = 3; growthRatio = 4 |
| 05 Switch | Ended, complete window; 12 ≥ 10 and 12 ≥ 2 × 3 | SURGE |
| 06 Memory | Prepare inputs, rules, evidence, stage details and final result | Reproducible circuit.trace.v1 record |
import { buildWorkbenchTrace } from './workbench.js';
const trace = buildWorkbenchTrace({
scenario: 'burst',
windowSeconds: 60,
multiplier: 1,
});
// trace.source.mode === 'example'
// trace.count === 12
// trace.filtered.length === 0
// trace.baselineAverage === 3
// trace.growthRatio === 4
// trace.status === 'final'
// trace.path === 'SURGE'The activity graph shows the burst's timestamped inputs; the accepted series matches it because nothing was filtered. Comparator, Switch and Memory each perform one whole-window evaluation in the relative activity display. These are different units, not a temperature scale or six identical Pulse counters.
Read the mechanism, then inspect it.
- Does SURGE mean buy or sell?
- No. It is the result of a deterministic display rule over an observed count, not a forecast or valuation.
- Why is an empty-looking circuit sometimes pending?
- Missing evidence is different from a reconciled empty window. QUIET requires complete coverage, complete parsing and an ended window.
- What works before a target is configured?
- Local Workbench, full component inspection, the public Source workspace, saved-record import/export, replay and PNG Snapshot export. Live target observation needs a new mint and at least one explicit account or pool.
- Does the system continue collecting when the page closes?
- No. This version checks while open and visible. Memory persists only in this browser until records or browser storage are removed.
- Can importing JSON prove an on-chain event?
- No. The engine can verify internal consistency. Independent chain provenance requires a successful read through the configured observation scope.
Implementation references
public/config/rules.js— window, baseline, thresholds and memory limits.public/modules/engine.js— actual processing contract and strict Trace validation.public/modules/instruments.js— relative activity, epoch-aligned buckets displayed in US Eastern time, waveform units and event paths.public/modules/workbench.js— deterministic local parameters and execution controls.public/modules/memory.js— bounded local persistence and JSON exchange.- Source workspace — actual public file contents and measured file statistics.
Test the mechanism.
Fixed inputs. No transactions, signatures or changes to live observation.