Market digital twin
Two separate private research systems on prediction markets. One models a participant's behaviour. The other competes on latency and analysis.
This is not one project. It is two independent systems that happen to share a domain: a behavioural digital twin that infers how a participant decides, and an execution engine that turns a public event into a position before the market has finished pricing it.
System one. A behavioural twin, not a copy machine.
The first system reconstructs a public wallet's history into an evolving behavioural state: markets selected, entry and exit timing, position sizing, exposure, holding periods and category concentration. Machine-learning and statistical models then estimate the decision logic that may explain those historical actions, with confidence attached, never as a guarantee it can be reproduced.
The twin is not a visual clone. It reports what it does not know: model uncertainty, per-behaviour confidence, and the divergence between simulated and observed activity. A widening divergence lowers confidence rather than being quietly absorbed.
The purpose is a research question, not a signal feed: does this participant follow a repeatable decision process, or does the pattern dissolve under scrutiny? Most do dissolve. That answer is the output.
A twin does not care whether the thing it models is a trader or a furnace. Model the behaviour, simulate the change, act on the prediction. Applied to an industrial process, the same loop optimises combustion and cuts emissions.
System two. An edge built from latency and analysis.
The second system is an execution engine. It acquires data from sources that were never designed to be consumed programmatically: reverse-engineering undocumented APIs, connecting directly to websocket feeds through a reverse proxy, and normalising what comes back into a stream that can be reasoned about in milliseconds.
From there it parses and validates the event, matches it to an active market on Polymarket, evaluates the position statistically, and executes the buy or sell through the market's blockchain infrastructure, all inside a budget measured in milliseconds. The advantage is twofold and deliberate: being earlier than other participants, and understanding the data better once it arrives.
Instrumented internally at every stage: detection, parsing, decision, transaction build, submission, with blockchain confirmation timed separately. The figures stay with the system; what is shown here is the design target, not a measurement.
Most of the value was never in the model. It was in getting a difficult source, reliably, and keeping it clean. Any business whose edge is a feed nobody else has stabilised can run this same pipeline.
It runs on its own, and that is the whole risk.
The execution engine is fully autonomous. It reads, decides and submits without me in the loop, because a system built to act inside a hundred milliseconds cannot wait for a human. That is a deliberate choice, and it is only defensible because of two things: the system is strictly for my own internal use, and I went into it understanding exactly what a bad decision costs.
The money is what makes the design conservative. Stop-loss logic, exposure ceilings and expected-value filters are not features bolted on afterwards, they are the reason the thing is allowed to run at all. A position that cannot be bounded is a position the system does not take.
In its own operation it runs at positive expected value and has been genuinely profitable. That result belongs to this research and to no one else: it is not for sale, it will not become a product, and nothing here is an offer, a signal service or financial advice.
Nothing here is published, and nothing will be.
Why this page exists
- To describe how I think about a hard systems problem
- To show the engineering, not the mechanism
- Everything shown is illustrative and synthetic
What stays private
- Wallet identifiers, endpoints, credentials
- Which sources are consumed, and how
- Strategies, parameters, thresholds, signals
- Latency figures and anything reproducible
It is private research exploring public blockchain data, prediction-market behaviour and automated execution. It is not financial advice, an investment product or a signal service. Automated trading carries real financial risk, and this engine is bounded by stop-loss logic and exposure ceilings rather than by a human watching it.
Two systems, one engineering discipline.
The behavioural system combines public blockchain-event ingestion, data normalisation, feature engineering, clustering, supervised models, time-series analysis and simulation.
The execution system adds websocket ingestion, reverse proxies, event parsing, market matching, risk limits, transaction construction and stage-by-stage latency instrumentation on controlled Linux environments.
Useful wherever decisions depend on a difficult live feed.
The transferable value is resilient acquisition, clean event models, measurable decision pipelines and explicit operating limits, not the private strategy itself.