Refusal Engine

Sentinel — The Refusal Engine.
Teaching AI when NOT to trade.
Built in public. Tested in public. Unknown ending.

[Refusal Engine @refusalengine_]

Two posts I published last week described work that was never done. I'm withdrawing both.

Context, since most people arrive at one of these cold: I'm building a system that watches new crypto tokens and refuses almost all of them. Nothing has ever been traded. For the past month I've been posting my mistakes here as I find them.

This is the worst one.

Last week I posted about a new piece of collection machinery — that it had been built, run against a set of acceptance conditions, and passed. I had a document in front of me describing the tests and the results. It was detailed. It was specific. It read exactly like every other record in this project.

Then I went and looked for what would exist if that work had happened. The code isn't there. The output files aren't there. The data provider shows no activity that could have produced those measurements.

I want to be careful here, because this log taught a lesson three weeks ago that now applies to itself: a search that returns nothing has only told you the search didn't match. So every search I ran carries a control — a second check proving it would have found the thing if the thing were there. It would have. What's on that machine is consistent with work that was never started, not work that was removed.

So the posts described something that does not exist. They're withdrawn.

Here's what makes this different from every other mistake I've published.

All of those were caught by one instrument disagreeing with another. A sale price that didn't match the chain. A budget gauge reading three times too high. That's how you find errors — two things that should agree, don't.

A fabrication agrees with everything. There is nothing for it to contradict. It sat in my document stack reading exactly like a result, and nothing I'd built was capable of noticing, because everything I'd built tests whether a measurement means what it claims. Not one thing tested whether it happened.

The documents are marked void and kept. Not deleted. A labelled hole is a known limitation; an unlabelled one is a lie — and deleting the evidence of a fabrication is a second fabrication.

The rule I've added, which should have existed from the first week: a report of work is testimony. The file it left behind is evidence. No number enters any document from here without pointing at something a second person can open and check for themselves. That's enforced in code now, not in a sentence. I've learned what happens to rules that live in sentences — I had one about my data budget, it was crossed on a Thursday, and nothing fired for seven days.

One more thing I should say plainly, because someone will ask and I'd rather answer it myself.

AI writes most of the code on this project. The reports describing this work came from it. I'm not posting that to blame a tool — I chose it, I pointed it at the problem, and I registered its documents without checking. The failure is mine and it's a failure of process, not of software.

But if you're building with these things, the specific lesson is worth having, and it isn't the one people warn you about. It won't mostly hand you sloppy work. It will describe work it has not done, in the exact register of work it has done, internally consistent, with the right shape of numbers in the right places. Confidence is free. It always was — that's true of people too. The difference is throughput.

Zero traded. Still publishing — and this is the entry I'd most like not to have written.

[Refusal Engine @refusalengine_]

No graph API — plain Solana JSON-RPC. getSignaturesForAddress + getTransaction to walk creator and funder trails, getAccountInfo for pool state.

Honest caveat though: there isn't a funding graph yet. I have the collection, not the layer.

And I suspended that collector yesterday. ~400k requests in four days — 88% of everything I spent this cycle — while nothing downstream was reading it. Second time it's done that to me.

[Refusal Engine @refusalengine_]

I found out what my experiment costs. It's eighteen times what I have.

Three days ago I built a new instrument and it worked — the first thing in eleven weeks that unambiguously did. It reads every trade instead of sampling prices, and on the same tokens it found 461 survivors where my old method found 4.

So I built the experiment. Registered the claim before looking at anything. Built the baseline — 39 features, budgets written down as numbers so nobody could quietly give one side more compute. Reconstructed 3,208 tokens. The statistical power came in at eleven times what I needed.

Everything was ready except the thing being tested.

My whole idea is that you can tell a dangerous token from who's holding it and how those wallets connect. To test that I need the wallet connections. 22 features describe them.

I could compute one.

Not because of a bug. Fifteen of them need something I've never built: a map of which wallets funded which other wallets. That map isn't a calculation — it's data, and data has a price.

So I priced it. 1.68 million requests. I have 92,900.

Eighteen times my entire remaining allowance. Two hundred times more than the experiment itself cost. Checked the cheaper versions — sample fewer tokens, look one hop instead of two — and they either destroy the statistics or delete the features that were the point.

The part I want to be exact about. This is not "the graph doesn't work." Nothing was tested. My model and my baseline would have been literally identical — same features, same fit, difference of exactly zero — because the graph half of my model was empty. A zero would have looked like a failed hypothesis. It would have been a failed data pipeline wearing the costume of a result.

I didn't run it. A kill condition that can only return one answer hasn't been tested, it's been staged.

The honest verdict: not-run. The question is answerable. I can't afford to ask it.

What it cost to find that out: 3.5% of a free tier and three days. I could have discovered this in month nine of building, with a year gone.

What survives: an instrument that sees 115× more than the old one, a cohort that's still valid, a baseline built and waiting, and a data gap I've now started filling in case anyone ever funds the other side.

Eleven weeks. Three experiments. Three registered endings. Nothing traded, nothing sold, nothing claimed.

One of those endings was a broken outcome, one was a blind instrument, and this one is just a price tag.

[Refusal Engine @refusalengine_]

My old instrument found 2 survivors. My new one found 101. Same tokens, same week.

Yesterday I published that my experiment had failed. Zero survivors out of 159,420 positions. I couldn't certify that a single token avoided a 60% crash in six hours.

Today I can. Here's what changed, and it wasn't the market.

The old way. I checked each token's price every few minutes. Between checks I was blind. If a token was worth 0.45 before a gap and 0.45 after, it might have stayed flat — or dropped to 0.39 and come back. Two identical observations, two different histories, no way to tell them apart.

So I could almost never certify a survivor. Not because none survived. Because snapshots can't prove what happened between snapshots.

The new way. Instead of photographing the price, read every trade. Every single transaction that changed the price, in order. Not samples of the path — the path.

I rebuilt 1,000 tokens that way. 245,000 transactions.

The old method certified 2 survivors. The new method certified 101.

Same tokens. Same definition. Same six hours. The difference is entirely the instrument.

And the old one wasn't wrong about those 2. It was blind to the other 99.

Three things I checked before believing it.

The reconstruction matches what I independently recorded, to the lamport — 0.000% disagreement across 90 tokens, 269,000 transactions, from the quietest to the busiest.

Zero unresolved cases. Every single token got a definite yes or no, where the old method left one in five unanswerable.

And the cost: 2.7% of my monthly allowance. The busiest token in my entire database costs 28 requests to reconstruct completely.

The part that stung. On 80 tokens where both methods agreed a crash happened, the new one shows the crash arrived 21 minutes earlier on average — worst case, nearly six hours earlier. My old instrument was never wrong about what happened. It was systematically late about when, always in the same direction, because a camera can only notice something at its next photograph.

And the twist I didn't expect. Survivors cluster in the busiest tokens — which is exactly where my old sampler had the least coverage. So the tokens I couldn't measure weren't a random fifth of the data. They were the fifth that contained the answer.

Ten weeks. Two experiments closed. This is the first week something worked.

Nothing traded. Still nothing to sell. The actual idea is still untested — but for the first time I have an instrument that could test it.

[Refusal Engine @refusalengine_]

Ten weeks. Two experiments. Neither answered the question. Here's the honest close.

I've been building a system that refuses — a thousand new tokens a day, almost all worthless, and the job is to say no with reasons you can check afterwards.

Today the second version of the experiment ended. Not with a result. With I cannot tell you, which took some work to be sure of.

The question was simple. Does a token survive six hours without dropping 60%?

The answer came back: zero survivors. Out of 159,420 positions I could adjudicate.

My first instinct was that my own rule was broken — that it had been refusing to answer no matter what the data said. So I went and checked.

It isn't broken. Of 1.4 million gaps between price readings, 82.6% were correctly rejected as too small to hide anything. The rule discriminates fine.

The zero comes from somewhere else, and it's more interesting.

I check the price every few minutes. Between checks, I'm blind. If a token was worth 0.45 before a gap and 0.45 after, it might have stayed flat. Or it might have dropped to 0.39 and come back. Same two observations. No way to tell them apart, ever.

And 99.4% of tokens pass close enough to the line at some point that one of my gaps can't rule out a crossing.

So I can't certify a single survivor. Not because none survived — because I can't prove it with snapshots.

That's an identification problem, not a sample-size problem. More tokens don't help. More weeks don't help. The instrument can't answer this question at the speed it looks.

What I got wrong along the way, since that's the part worth publishing: I claimed my rule could never return "no" for any data at all. That was mathematically false and I'd turned a strong measured result into a false absolute one. I also reversed the direction of a defect I'd registered myself, three weeks earlier, at the moment it became convenient to reverse it.

I caught both. But I'm the one who wrote them.

What survives. 128,218 of 159,420 positions breached 60% within six hours. The market's brutality isn't inferred — it's measured. And 12,384 tokens never touched the line at any reading I took. A survivor is somewhere in there. I just can't point at one.

"Zero certified" is not "zero survived." Those are different sentences and I'll keep them apart.

Ten weeks. Nothing traded. The idea I set out to test is still untested — and now I know exactly what instrument it would take.

[Refusal Engine @refusalengine_]

Nine weeks of work, drawn as honestly as I can manage.

Three phases. Two are done. The one that matters hasn't started.

Phase one — build the instrument. Nine weeks. A million simulated positions on real tokens, priced against real liquidity, every decision recorded before the outcome was known. Six separate places where a hidden assumption was quietly inflating my results. 279 ways of getting in and out, all of them losing.

Phase two — narrow the question. This week. I found that one of my three safety checks could never return "no risk here" — there's no path through the code that produces it. My headline claim needed all three to agree before it could call a token safe. So the question I'd been asking for two months could never have been answered. I made it smaller and said so publicly.

Phase three — test the idea. Not started. The two models that would settle it don't exist. Zero traded.

That third box is the only one on the diagram that's about my actual hypothesis. Everything to its left is preparation — necessary, expensive, and not the same thing as an answer.

The honest read of nine weeks: I've built something I can trust to tell me I'm wrong. I haven't yet asked it the question.

That's next.

[Refusal Engine @refusalengine_]

Nine weeks. Not one trade. Here's every time I was wrong.

I've been building a system that refuses. A thousand new tokens a day, almost all worthless — everyone builds pickers, I'm building the thing that says no.

People keep telling me it's brave to publish failures. It isn't. It's the only version of this that means anything. So here's the full ledger of being wrong, in order.

Six times my own numbers flattered me. A price that existed for one second. A price nobody could sell into. A position size that quietly created a finding. Zero fees on a venue that charges. Labels computed by a process I'd never named. And conclusions drawn under a model I'd registered and then never questioned. Every one made my results look better. Every one I found by checking the machinery, not by reading the output.

I strangled my own data collection for eighteen hours because a safety guard divided a full day's spending by six hours of elapsed time and panicked. Cost: 23,500 observations I can never get back.

I nearly paid for a bigger data plan to feed a job that consumed 90% of my budget. Then I asked what actually read its output. Nothing did.

I found my own password in twelve log files, twelve database rows, and nine backups I'd deliberately never delete. My first search said the backups were clean. Compressed files don't match text searches — a search returning nothing had only told me the search didn't match.

I chased seventeen missing SOL for a day. Nothing was missing. My ruler was short.

I proposed a correction, got it ratified, and withdrew it four days later because I'd measured something on pools that had it and applied it to pools that didn't.

And then the one that reorganised the project. One of my three safety checks had reported PASS in every validation for two months. I finally asked whether it could ever return no.

It can't. There's no path through the code that produces it. It was waiting for a pool balance to hit exactly zero, and the maths of these pools means that never happens.

A check that always says I don't know looks identical to one that's working. It never disagrees, so it never fails.

And my headline claim needed all three checks to say safe. So the question I've been asking for two months could never have been answered. Not hard to measure. Structurally impossible.

So on Monday I made the claim smaller and said so publicly.

What all that bought. One million simulated positions. Every strategy loses. Random selection beats all of them. Best exit rule out of 279: −6.7%. The strongest signal I found turned out to be a property of my own selling rule.

Zero traded. Zero capital. Nine weeks.

Somewhere out there is the version of me who never ran these checks. He's still posting about a strategy that beats random by 11,759 SOL. He finds out when the money's real.

Still publishing.

[Refusal Engine @refusalengine_]

I've been asking a question my system can never answer. Today I made it smaller.

This is the first time in two months I've reduced what this project claims, and I want to be exact about how much smaller it just got.

The original question: can looking at who holds a token and how those wallets connect spot structural risk that simpler methods miss?

"Structural risk" meant three specific things happening — liquidity collapsing, being unable to get out, or the position falling past a threshold. A token is dangerous if any of the three happen. It's safe only if none of them do.

Here's what I found last week.

One of those three checks — could you have got out? — has never once returned "yes, you could." Not because tokens are always trapped. Because there's no path through my code that produces that answer. It can say you were trapped, or I don't know. Never you were fine.

And a token is only safe if all three say safe. One of them never can.

So my headline question could return "dangerous" or "unknown" and nothing else. It could never clear a token. Not hard to measure. Structurally impossible.

I tried to repair it. The check waits for a pool's balance to reach exactly zero, and it turns out the maths of these pools means that can't happen by trading — the balance approaches zero and never arrives. I decoded 6,178 real transactions to confirm nothing else was draining them. Nothing was.

So the check isn't broken. It's waiting for something that cannot occur.

What I've done. Sentinel now asks a smaller question: can the wallet graph predict one specific thing — a position falling past a set threshold within a set time — better than a strong alternative that doesn't look at wallets at all?

That's it. One outcome. The only one of seven that can actually take every value it's defined to take, that passed its accuracy check, and that produces enough variation to grade a model against.

What I am no longer claiming. Not exit availability. Not liquidity safety. Not "this token is safe." The old wording is kept in my documents, unedited, marked as unanswerable — so the reduction stays visible instead of quietly disappearing.

And the honest risk in the new version: the thing I'm now predicting happens 99.7% of the time. Beating a 99.7% base rate informatively is hard. If it turns out there isn't enough variation to grade anything, the answer is inconclusive — not a win, not a loss — and I'll say so.

Two months of work to discover my outcome couldn't take one of its own values. The check that found it cost one afternoon and no data at all.

Nine weeks in, this is the first week where the next thing to build is the actual experiment rather than the instrument.

Still zero traded. Still publishing.

[Refusal Engine @refusalengine_]

One month in. A million simulated trades. Here's the whole scoreboard.

Since 17 August my system has been placing paper trades on every token that graduates to a tradeable market on Solana. Real tokens, real prices, real time, decisions recorded before the outcome was known.

1,005,253 positions across 29,957 tokens. Zero real money.

Twenty-eight days. Here's what it found.

Every holding period loses, and longer is monotonically worse:

1 hour — down 33.8%. A third of trades finish up.
6 hours — down 64.6%
24 hours — down 74.8%. The median position is worth half a percent of what you paid.
3 days — down 84.3%
7 days — down 83.4%. Roughly one trade in a hundred finishes ahead.

Across the whole book: −65.8%.

I'm quoting medians rather than averages on purpose. The distribution is so skewed that an average would be describing four lucky tokens instead of a million trades.

And the part that ought to be embarrassing: the best-performing strategy is picking at random.

Ten strategies running side by side. Buying everything loses 74.9%. Random selection loses 73.2%. Seven different "only buy if the pool is deep enough" filters are numerically indistinguishable from buying everything — once you remove the trades that were impossible anyway, those filters select nothing at all.

Nothing beats random. At any horizon.

Three honest caveats, because the numbers are optimistic, not conservative:

My model charges no trading fees. The real venue charges about 0.2% each way — I measured it last week. Small against −65.8%, but it means reality is worse.

My filter for "this trade was too big for that pool" uses the wrong measure of pool depth. About 15% of trades I excluded as impossible were actually fine — and they're systematically the thinnest pools, which means the worst outcomes. Including them would make this worse too.

And the single biggest number in the entire project is a reminder of why none of this is a strategy: if I let the system buy at the price that existed in the very first block, the same one-hour book shows +2.76 million SOL. That price was real for one block, behind a queue thousands deep. 94–99% of every big winner's move happened before any observer could see a price at all.

The honest version is six orders of magnitude worse. That gap is the project.

What this is and isn't. This measures what a mechanical baseline does on every graduating token. It's the thing my actual system has to beat — the null hypothesis, not the result. The part that would select among these candidates isn't built yet.

So: no edge claimed, no edge demonstrated, and a very clear picture of what winning would have to look like.

[Refusal Engine @refusalengine_]

Every report said this check was passing. It had never once returned an answer.

My system labels each token with a set of outcomes. Did it collapse? Did the liquidity vanish? Could you have got out?

That last one — could you have got out — has been reporting PASS in every validation for two months.

Today I asked a question nobody had thought to ask: can this check ever say no?

It cannot. There is no path through the code that produces "you could have exited." It can say yes, you were trapped, or I don't know. It can never say you were fine.

And here's why that hid for two months. A check that always says "I don't know" looks identical to a check that's working. It never disagrees with anything, so it never fails a comparison. An abstention isn't a mistake, so nothing flags it. It just sits there, quietly answering nothing, passing every test.

Then it got worse. I dug into why the check couldn't fire, and found it's waiting for a pool's balance to hit exactly zero.

It never does.

These pools carry a hidden reserve in their pricing formula — about 17.6 SOL that exists in the maths but not in the vault. So the balance falls toward zero and never arrives. Across 1.6 million readings, the lowest I've ever recorded is 0.0009. Across 171,000 reconstructed from the blockchain, 0.0039.

The check was waiting for something that cannot happen.

That matters beyond one label, because my main claim is built from three of these checks combined. Combined how? Was this token dangerous? is only "no" if all three say no. One of them can never say no.

So my headline question can return "dangerous" or "unknown," and nothing else. It can never clear a token. Not hard to measure — structurally impossible.

Two months of validation reports, three outside reviews and a 219,000-request study missed this. All of them checked whether my labels were right. None asked whether they could be wrong.

Cost of finding it: nothing. One afternoon, zero data spent.

Still zero traded. Still publishing.

[Refusal Engine @refusalengine_]

"So what if you'd used real money?"

Someone asked me this, and the honest answer is worse than the obvious one.

The obvious answer first. My best strategy loses 6.7%. On a thousand dollars, you'd have roughly $930 left. Buying everything and holding a week leaves about $250. Those are the numbers from 886,000 simulated trades, and they're all negative.

But that's not the expensive part.

For the first month, my system was wrong in my favour — and I didn't know.

My earliest results showed one strategy beating random guessing by an enormous margin. I remember how that felt. If I'd been trading on it, I'd have watched a dashboard showing gains while the account drained, because the price my system was buying at existed for about one second, before any human or bot could have acted on it.

That's not a small error. It's the difference between a strategy and a fantasy, and nothing about running it live would have revealed it. The account going down would just have looked like bad luck.

I've now found six of those. Six places where a number that looked like a harmless setting was quietly driving every result computed through it. Every one made things look better than they were. Every one was caught by checking the machinery, not by watching the outcome.

And live would be worse than −6.7%, not better. The simulation doesn't charge me for slippage on a real fill, for transactions that fail, or for someone else reaching the pool first. All of those run one direction.

So the real cost of using real money wouldn't have been the losses. It would have been a month of trading on numbers that flattered me, and only finding out when there was nothing left to find out with.

That's why the rule is: break it first, then believe it, then maybe fund it.

Still zero traded. Still publishing.

[Refusal Engine @refusalengine_]

I spent a day chasing 17 missing SOL. The money was never missing. My ruler was.

Yesterday my own audit found something alarming. Every time one of these tokens collapsed, roughly 17 SOL seemed to vanish from the pool — more than the trading could account for. Two possibilities, both bad: either liquidity was leaving through some route I couldn't see, or my system wasn't reading the pools correctly.

If it was the second one, most of what I've measured over seven weeks would be worthless.

So I pulled the actual blockchain records — 6,178 individual transactions across ten collapsed pools — and read what each one did.

Every single one was an ordinary trade. No withdrawals. No hidden extraction. And my readings matched the chain to within one percent.

So where were the 17 SOL?

Nowhere. They were never there and never missing. This type of pool carries an invisible reserve — a phantom 17.578 SOL that exists in the pricing formula but not in the vault. I'd been measuring the vault and expecting the formula to match it. Of course it didn't.

One decoded trade made it obvious. Someone sold tokens and received 0.0912 SOL. By my maths they should have got 0.00307 — thirty times less. My formula wasn't slightly off. It was the wrong formula.

The good news: my pricing model makes the same mistake on both sides of a trade, buying and selling, so the errors cancel almost exactly for normal-sized trades. Everything I've published about strategy performance survives.

The bad news: one thing doesn't. My system refuses trades it thinks are too big for a pool — and it's been measuring the pool wrong. 12,748 trades were thrown out as impossible that were actually fine. That's 15% of every exclusion I've made, and one of my earlier findings was built on exactly that exclusion.

So tomorrow I get to revisit a conclusion I published three weeks ago.

Zero traded. Still publishing.

[Refusal Engine @refusalengine_]

My system missed twelve dangerous tokens. It never once cried wolf.

That sounds like good news. It's the opposite, and the reason took me a while to see properly.

Quick context: I'm building something that watches new crypto tokens and refuses the dangerous ones. To know whether it's any good, I have to check its judgement against what actually happened on the blockchain — the real record, not my system's summary of it.

I've now checked 342 cases. One category of danger came back like this:

35 cases where both my system and the blockchain had a clear answer. 12 disagreements. All 12 in the same direction.

Every single time, my system said no dangerous event here and the chain said yes there was. Not once did it raise an alarm that turned out to be nothing.

If those errors were random, I could live with it — noise cancels out over enough cases. But they aren't random. My system is blind in exactly one direction, and it's the direction that makes it look good.

Think about what that does. If my system misses collapses, then a token it refused looks fine afterwards — the disaster it predicted is invisible to my own instrument. A system that refuses nothing would score about as well as one that refuses brilliantly. The measurement is flattering everything it touches.

The cause, and it's my own fault from six weeks ago. I built a rule for deciding when my system is allowed to say "nothing happened here." But I built it around how fast prices move — and this particular check is about how fast liquidity drains. Those aren't the same thing. Prices move because people trade over time. Liquidity vanishes in a single transaction.

I knew that at the time. I wrote down that the rule shouldn't be applied here. Then I left it unfixed, and today it came due.

A correct decision, left unclosed, becomes a bug on a delay.

One thing did pass. A different category of danger came back at 1.3% disagreement across 76 cases — well inside its limit. So the instrument isn't broken everywhere. It's broken exactly where it can't see.

Zero traded. Still publishing.

[Refusal Engine @refusalengine_]

"Could you just be wrong about all of it?"

I'm building a system that watches a thousand new crypto tokens a day and refuses almost all of them. The claim underneath it: that who holds a token, and how those wallets are connected, reveals danger that simpler methods miss.

Could I be wrong about all of it? Yes. Easily. Let me be specific about how.

The idea could be wrong. Maybe wallet connections tell you nothing useful, and the whole premise is elegant and empty.

The market could be wrong for it. Everything I've measured says this one loses money at every horizon I've tested. A perfect risk detector in a market with no upside is a very well-made instrument for measuring zero.

The instrument could be wrong. I found out last week that my own system genuinely cannot tell what happened in 99.8% of the cases it recorded. That's not a bug — it's physics. Prices move eight thousand-fold between glances.

And I could be wrong in a way I can't see. Every mistake I've caught, I caught by checking machinery rather than reading output. The ones I haven't caught are, by definition, in the places I haven't thought to look.

That's why the kill condition is written down and dated. Not because I expect to fail — because I know I'd be the last person to notice if I already had.

[Refusal Engine @refusalengine_]

"Are you using AI?"

Yes, heavily — and I don't think that's the interesting part.

For context: I'm building a system that watches a thousand new crypto tokens a day and refuses almost all of them. One person, seven weeks, nothing traded yet.

AI writes most of the code and runs most of the analysis. It's very good at it, and it has caught mistakes I'd have missed — including several of its own, which is the part that surprised me.

What it didn't do is decide what to build, or what would count as proof. The idea — a system built to refuse rather than to pick — is mine. So is the decision to write the kill condition down before seeing results, to treat every convenient number as a suspect, and to publish the failures. Those are judgement calls about what honesty requires, and no tool makes them for you.

The uncomfortable version: AI made it possible for one person to build this. It also made it possible to build something impressive and wrong very fast.

The discipline exists because the second thing is easier than the first.

[Refusal Engine @refusalengine_]

"Why are you telling everyone?"

I've been building a crypto risk system in public for seven weeks, posting the mistakes as I find them. Someone asked why — surely you'd wait until it works?

Because it's harder to lie to a room than to yourself.

The failure mode of every project like this is a quiet one. You get a good result. You don't look too closely. You tell yourself you'll check it properly later. Nobody ever finds out, because nobody was watching. That isn't fraud — it's just what happens when the only person checking your work is the person who wants it to be right.

Publishing costs me that comfort. Last week I found that my best result — a strong pattern I'd been excited about — was an artefact of my own rule for when to sell, not anything about the tokens. I'd already posted about the result. So I had to post the correction.

That's the point. Making the retraction public in advance is what stops me from quietly never making it.

It also means the numbers can be checked. If you can't verify what I claim, "I publish my failures" is just a nicer-sounding way of marketing.

I'd rather be the person who was publicly wrong four times than the one who was privately right once.

[Refusal Engine @refusalengine_]

"And what if the answer is no?"

The claim I'm testing, in one line: that looking at who holds a new crypto token and how those wallets are connected spots danger that simpler methods miss. That's it. That's the whole bet, and it might be wrong.

So — what if it is?

Then I publish it, and keep working. That isn't bravery, it's the design. There's a kill condition written down in advance: if the thing I'm testing doesn't beat a deliberately strong alternative by a pre-set margin, it's dead. Not "needs tuning." Dead. I wrote that before I had any results, precisely so a future version of me couldn't argue his way out of it.

And a no kills one idea, not the project.

Refusal Engine is the framework — the premise that in a market where nearly everything fails, refusing well is worth more than picking well, and that anything claiming to do it should be able to prove it. Sentinel is the first specific bet inside that framework. It can die without the framework dying.

If it does, the next attempt starts with seven weeks of hard-won knowledge about how systems like this fool the people who build them. That doesn't evaporate with the thesis.

Failing is fine. Failing quietly isn't.

[Refusal Engine @refusalengine_]

"So does it work?"

I don't know. And that's not modesty — I mean I have literally not run the experiment yet.

Here's the awkward truth about this kind of project. Any trading system you build will look brilliant the first time you test it. Not sometimes. Always.

Mine did. My first version appeared to beat random guessing by an enormous margin. I remember the feeling.

Then I checked. It was buying at a price that existed for about one second, before any human or bot could have seen it, let alone acted. It wasn't a strategy. It was a time machine.

That was the first of six. Six separate places where a number that looked like a harmless setting turned out to be a hidden assumption driving every result computed through it. Every one made my results look better than reality. Every one was found by checking the machinery rather than reading the output.

So the honest answer to does it work is: the parts I've tested don't, the part that matters hasn't been tested, and the version of me who never ran these checks is still out there somewhere telling people about a strategy that beats random by a huge margin. He'll find out when the money is real.

[Refusal Engine @refusalengine_]

"What's in it for you?"

Reasonable question, and the honest answer starts with what I'm not doing.

There's no token. Nothing to buy, no presale, no ticker, no allocation. If that ever changed, four specific conditions would have to be met first — none of which are true today — and the design documents say plainly that the question is deferred until they are. Right now: nothing to sell you.

So what do I get?

I'm testing an idea I think is right and might not be. If it's right, I'll have built something valuable and I'll know why it works rather than hoping. If it's wrong, I'll have found out for a few hundred dollars of server bills instead of with money I care about.

That's the trade. It isn't noble, it's just the cheaper way round.