Stage 1 Registered Report · in preparation
Two regulators require a cooling-off period before a trader may raise their own limit. Neither published evidence that it works.
A4 PDF · the version that goes in an email
01 · The question
Written so that the interpretation of every outcome is fixed before any data exists. A hypothesis whose confirming and disconfirming results have not both been described in advance is not a prediction; it is a space to rationalise into afterwards.
A trader sets a limit on position size. They cannot take positions that large any more. So what do they do instead?
The possibilities are not equivalent. They might trade the same way with smaller positions, and lose less — the tool worked. Or they might take the same risk by trading more often, or holding longer, or using more leverage — the tool moved the behaviour without reducing it. Or they might stop using the tool.
This is risk compensation, known from other fields: seatbelts and driving speed, safety equipment and risk-taking. It has never been measured inside a single trading account across the dimensions of a tool set, because nobody has had account-level data on a person whose constraints were being experimentally withdrawn.
Why it matters practically. Every exchange and regulator now offers or mandates these tools. If constraining one dimension simply relocates the behaviour, a tool set that constrains one dimension at a time is theatre — and the correct design constrains total exposure rather than any single channel. That is an argument about how to build these tools, and it is currently being settled by assumption.
Two UK regulators already answered this, in opposite-facing ways, without evidence.
A 24-hour cooling-off period for first-time cryptoasset investors. Its only publication on its own rule is a compliance assessment containing no behavioural measurement.
A minimum 24-hour delay before a customer may increase a self-set limit, justified on the grounds that the delay allows reflection and prevents impulsive decisions. The consultation response cites no pilot and no effectiveness data.
So the 24 hours is a guess, enforced on millions of people. This study does not test whether 24 hours is the right number — no study of thirty people could. It tests whether the mechanism the number is supposed to serve exists at all: does making a limit harder to lift change what people do, and does it change whether they keep the arrangement?
The tension, in one line. A limit that can be lifted at will may not be worth setting. A limit that cannot be lifted may not be worth accepting. Somewhere between those is a design people will both adopt and be helped by, and nobody has looked.
Gambling has protective-tool research going back two decades. Retail cryptocurrency trading has almost none, while carrying the same structural features that make gambling harmful: continuous availability, rapid feedback, variable reward, and loss-chasing. Traders also set their own limits far more often than gamblers do, which makes the self-set limit a real behaviour to study rather than a hypothetical.
Participants trade their own money on their own exchange account, as they already do. The difference is that the limits they set are actually enforced: the system can refuse an order, trim a position, or stop them trading for the day. The outcome measures are their real orders, not their recollection of them.
02 · Hypotheses
Each one below carries its registered statement, why it is worded that way, the prior it runs against, and — the part that matters — the interpretation of each outcome, fixed now. Click an outcome to see what it would mean.
No published study has asked participants to connect their own live trading account to a researcher's system. How many reach each stage, where they stop, and how many silently revoke access are quantities nobody has measured. Recorded stage by stage, with credential generation as its own step because it is the expected point of failure.
How often each constraint actually stopped something. Without it, a null result on H1 is uninterpretable.
What was asked for, when, the reason given, and the participant's state at that moment — in both arms.
Recorded in advance so it cannot be redefined afterwards.
| Failure | Why |
|---|---|
| Fewer than ten participants connect | No within-subject analysis is possible |
| Constraints never bind for most participants | The displacement analysis has nothing to work with |
| Attrition above half before day forty-five | Blocks four and five are unobserved |
| The fixed arm empties before day ninety | H5 is answered in the direction predicted, and H1 loses that arm. Both are reported; the second is not concealed by the first |
| A defect is found in a control during the study | The data from that control is discarded, not adjusted |
03 · The finding
H1 says that suspending one constraint raises intensity on a dimension it did not govern. The five constraints share state — equity, the trading day, the cooldown clock — so withdrawing one changes what the others permit. H1 could be confirmed by arithmetic, with no behaviour involved at all.
A Monte Carlo simulation under a strict behavioural null tests this: participants whose latent appetite is drawn once and never varies by block. Any difference the analysis detects is therefore mechanical. The registered analysis was then run on that data.
H1 as originally registered returned a false positive in 100% of replications. Not inflated — certain. The hypothesis was unfalsifiable as written.
The first repair restricted H1 to the constraint–dimension pairs that stayed clean. That helped, and then the simulation itself turned out to model cooldown logic the instrument does not implement: the wrong streak threshold, both cooldowns applied where the engine picks one, and no carry across the day boundary.
| withdraw → dimension | registered | defaults | live | corrected |
|---|
Coupling is a property of the limit vector, and participants choose their own limit vector. cooldown → trades_per_day is 89.5% under the paper's illustrative limits and 0.0% under all three engine configurations. streak_cooldown → trades_per_day is the exact reverse. The sequence 10 → 8 → 7 safe pairs is not converging on a true number; it is three samples from a function the design lets participants set.
Register the procedure: fit each participant's behavioural parameters from their own control blocks, simulate the mechanical null under their realised limits, and test observed displacement against that participant-specific null rather than against zero. The simulation stops being a robustness appendix and becomes part of the analysis.
A 1,440-minute streak cooldown armed on the second consecutive loss couples so hard that withdrawing it returns false positives in 100% of replications on two dimensions. That is what a participant gets if they never adjust anything — so the defaults are not a safe fallback, they are the most coupled setting in the design.
04 · The design
A component-withdrawal design, borrowed from psychotherapy dismantling and single-case ABAB methodology. Every participant receives every condition. Nobody is randomised into a no-protection arm, which would be indefensible with real money.
Each block runs 18 days: 3 days of washout, then 15 analysed. In each block exactly one constraint is suspended while the other four stay in force. Order is randomised per participant.
Adding a constraint confounds the constraint with the novelty of being newly constrained. Withdrawing one from a set already in force isolates that constraint's contribution against a stable baseline.
It is also the ethical direction. Every participant spends most of the study fully protected, and the suspension is disclosed: /status names the constraint that is not enforced today.
Three separate mechanisms were found in the acceptance run that make the withdrawal a no-op without anything recording that it was: cooldowns ignoring the withdrawal schedule, an inverted cooldown pair, and a cooldown armed a minute after the event it responds to. All three bias toward the null and none is visible in the output.
The design change they all point at: record, per participant per block, whether the withdrawn constraint was capable of binding at that participant's own settings. A block in which nothing could have happened and a block in which nothing did happen must not be the same row.
This runs the same rule the instrument now runs, added in response to the defect below. Set the five limits and see which constraints are reachable.
05 · The instrument
The whole system is a Telegram bot with a Postgres database and a sixty-second monitoring cycle, holding one exchange credential per participant. Click a stage.
Equity read, fills detected and scored, breaches assessed, cooldowns armed, outside trades caught. One cycle takes about six seconds for one participant.
Due limit requests applied — the delayed arm's waiting period elapsing, with no human in the loop by design.
Invariant checks over the database. A violation names the offending row, exits non-zero, and now reaches the operator's phone.
systemd OnFailure alerts if the service dies. Gap: no heartbeat, so a machine that loses power reports nothing — a dead machine cannot send its own alert.
Python 3.12 · aiogram 3 · SQLAlchemy async · PostgreSQL · APScheduler · ccxt · alembic — a systemd unit on a single VPS, exchange access through Bybit EU spot.
06 · Commands
Thirteen. The set was cut back to what the study actually needs — every command here either does something for the participant or is required for their exit. Each one opens: what it does, what comes back, and whether it has been exercised against the live account or only read in the source.
07 · Safeguards
Every protection, what it prevents, and how it is checked — because a safeguard nobody verified is the failure mode this project has already produced once.
Trade-only, with withdrawal permission disabled. The system asks the venue itself whether the key can withdraw and refuses it if it can — and refuses a key whose permissions it cannot read. It is bound to the server's address at creation, encrypted at rest, and deleted from the chat on receipt.
No withdrawal function exists anywhere in the codebase. Not disabled, not permission-gated — absent, established by exhaustive search rather than by any module's claim about itself.
Holdings that predate connection are never force-closed. That line is enforced in code rather than stated in a document: those holdings have no lot record, so the system cannot see them to close them.
Nothing may refuse an order that reduces exposure. Every constraint governs opening and enlarging; none governs exit.
A published thirteen-item scale for trading-related problem severity, administered in full and without paraphrase, before any credential is in the system.
The item concerning suicidal ideation is handled separately: a positive answer halts the questionnaire at that point rather than asking someone who has just disclosed it to complete twelve more, shows crisis resources before anything else, excludes the participant, and escalates to a named person. Screening will not run at all without that person configured, which is why the study has not begun.
Triggers are fixed before recruitment and set below the point at which harm is established, because the purpose is to look early rather than act late: repeated loss-ceiling days, cumulative loss over a rolling window, deposits above baseline, any disclosure of chasing or borrowing to trade.
The reviewer is not the researcher. A researcher with an interest in retention is the wrong person to decide whether a participant should stay.
/status on every use.08 · The audit
A 108-check acceptance protocol run over two sessions — the first by code inspection, the second by placing real orders on a funded account. Twenty-two defects, nine closed.
After the inspection session the record concluded that not one defect lived in the enforcement engine — the module set with four months of live exposure — and that here, exposure predicts defect density while complexity does not.
Then one order found D69: the post-loss cooldown is armed by the monitoring cycle rather than by the closing trade, leaving up to sixty seconds in which a participant can close a loss and immediately re-enter — the exact impulse the control exists to interrupt. Every module on that path is individually correct. The property that fails belongs to the order in which two of them run. Reading each module confirms each module.
A component returns a plausible, internally consistent, wrong result and nothing downstream can tell.
Four layers each read as confirmation of the one below, and none of them checks anything.
A safeguard nobody ever made fire on purpose. Every defect this project has found lived in one.
A check whose scope silently excluded the thing it was checking for. Found four times — twice inside the verification apparatus, once inside a fix commit.
Eleven predicted behaviours were refuted by the system during the run, and the wrong predictions produced better results than the right ones. The method each time: predict, be wrong, then design the order that distinguishes the explanations. The full record carries both evidence lines for every check and a reason for every omission.
09 · Where it stands
The enforcement side is mature: four months of live operation, defended by invariants, and now with two constraints shown to refuse a real order rather than asserted to.
The measurement and analysis side is the part that is not built, because there has never been anything to measure. That is a better thing to know now than in month four, and it is what a supervisor should be told plainly rather than discover.