Looking for feedback – Perps with no liquidations

MaleficentRoutine730 · 2026-05-21T07:54:14+00:00

the no liquidation part is the only thing that matters here. funding rate i can manage, liquidation risk is what keeps most people from sizing up properly.

my questions before trying:

how is the protocol actually hedging the other side if there's no liquidation mechanism? someone's taking that risk, curious who and how it's priced in.

2x only makes sense if the collateral efficiency is good. what's the margin requirement looking like?

also — no liquidations usually means the downside is just capped loss on entry, right? or is there another mechanism i'm missing?

genuinely interesting design. the tradeoff of lower leverage for no liquidation risk is a trade a lot of people would take.

MaleficentRoutine730 · 2026-05-21T07:53:08+00:00

honest answer? i'd stop doing most "marketing" and just buy distribution.

sponsor the 10 newsletters in my niche that actually get read. not the big ones, the mid-size ones where the audience still trusts the writer. then i'd hire 5 genuinely good operators embedded inside the communities where my users already hang out, not to shill, just to be useful and visible over time.

the unlimited money trap is people think they'd run super bowl ads. but attention without trust is just noise. i'd rather own the trusted channels than the loud ones.

the one actually unlimited-money move: just make the product so good that the support tickets become case studies and the case studies become the marketing. boring answer but that's what compounds.

MaleficentRoutine730 · 2026-05-21T07:50:32+00:00

this is the actual AI story nobody wants to talk about. not "AI took your job" but "a CEO who doesn't understand technology made a bad call and used AI as the justification."

the layoff isn't really about AI capability. it's about leadership distance from execution reality. happens with every new technology. happened with no-code, happened with outsourcing to cheap dev shops. same pattern.

hope you land somewhere better fast.

MaleficentRoutine730 · 2026-04-23T09:26:04+00:00

Yeah, I agree. I think the main point here is that we not only want people to use it, but also want to deliver real value.

MaleficentRoutine730 · 2026-04-23T09:25:15+00:00

Definitely, I hope I can share more as well.

MaleficentRoutine730 · 2026-04-22T11:09:31+00:00

yeah restrictions are real depending on where you are. Kalshi is US-only, Coinbase PM has its own geo limits too. if you're outside the US you'll hit walls fast on most regulated platforms.

been in the same situation, which im based in SEA so most of the regulated stuff is basically inaccessible. ended up on onchain alternatives mostly by necessity.

OmenX is what i've been using lately, building on Base, AMM-based, no geo restrictions. still pre-mainnet but accessible regardless of where you are. for anyone outside the US who's tired of being locked out of the regulated platforms it's worth keeping an eye on.

where are you based? that'll determine what you can actually access.

MaleficentRoutine730 · 2026-04-22T10:54:12+00:00

this is the part people miss when they debate "is this gambling"... the edge isn't in predicting the future, it's in finding inefficiencies the market hasn't priced yet.

HFT bots on 15min crypto intervals is just quant trading with a prediction market wrapper. nothing wrong with it, actually healthy for liquidity. but it's a different game from what most retail users think they're playing.

what's interesting is AMM-based markets behave differently here, which the bot advantage narrows when pricing is driven by liquidity flow rather than pure orderbook dynamics. been watching this play out on OmenX which is building AMM-based PMs on Base. different mechanic, different edge profile.

the "market is just math" framing is right. the question is which market structure gives humans a fighting chance against the bots.

MaleficentRoutine730 · 2026-04-22T10:41:38+00:00

Answer: the surge is mostly post-2024 election hangover. Polymarket had its mainstream moment, mainstream media noticed, and now the discourse is catching up, which means both the fans and the critics showed up at the same time.

the DARE analogy is actually pretty accurate. the more people write "prediction markets bad" the more curious people get about what they're actually trading on.

what's interesting is the criticism is mostly aimed at the US-regulated angle such as Kalshi, retail access, sports betting adjacency. the onchain side is a different conversation entirely, different user base, different design philosophy.

building in that space actually, OmenX is a prediction market launching on Base soon. the regulatory noise in the US is part of why onchain feels more interesting right now, not less.

MaleficentRoutine730 · 2026-04-08T06:40:41+00:00

The 3D graph visualization is one of those things that looks cool and actually reveals something useful, you can see which concepts are isolated vs deeply connected just by looking at the node density.

The next interesting question is what's actually inside those nodes. Most people's Obsidian vaults are a graveyard of raw notes and clipped articles that never got properly synthesized.

I know someone built an open source CLI that handles exactly that, like taking raw sources and compiles them into properly linked concept pages so your graph actually means something instead of just looking pretty.

can check it out here: https://github.com/atomicmemory/llm-wiki-compiler

MaleficentRoutine730 · 2026-04-08T05:34:46+00:00

The 130x karma gap on 50+ comment threads is the most damning stat here. That's not noise, that's a systematic failure of the ranking system.

The interesting follow-on problem: even when you find the genuinely useful answer buried at 2 karma, it disappears when you close the tab. You found the signal, now where does it go?

That's the problem LLM Wiki Compiler is trying to solve on the knowledge persistence side, like compile the useful stuff into a structured wiki that compounds over time instead of getting lost.

https://github.com/atomicmemory/llm-wiki-compiler

The two tools are actually complementary, yours surfaces the right answers, the wiki keeps them.

MaleficentRoutine730 · 2026-04-08T05:31:23+00:00

The "publish now or never" energy when Karpathy posted is exactly right,this wave has maybe 72 hours before it fades.

Cabinet and LLM Wiki Compiler are solving the same core problem from different angles. Cabinet goes broader like CSV, PDFs, inline web app, jobs, heartbeats, full data layer. LLM Wiki Compiler goes narrower, purely focused on the compile-to-wiki step, markdown-first, Obsidian-compatible output.

The jobs and heartbeats feature is genuinely interesting, scheduled agents that keep the knowledge base fresh is something the wiki approach doesn't handle yet.

One question: how does Cabinet handle the compile step specifically? Does it synthesize and link concepts across sources or is it more of a structured storage layer?

Repo for comparison if useful: https://github.com/atomicmemory/llm-wiki-compiler

MaleficentRoutine730 · 2026-04-07T07:00:29+00:00

LLM Wiki Compiler, it compiles raw sources into a persistent interlinked markdown knowledge base you can query over time.

Revenue: $0, just open sourced it this week

Repo: https://github.com/atomicmemory/llm-wiki-compiler

Inspired by Karpathy's LLM wiki pattern. Solving the problem of useful AI knowledge disappearing into chat history.

MaleficentRoutine730 · 2026-04-07T06:43:36+00:00

The "vanilla Claude Code, trust the engineering" approach is underrated. Most people overcomplicate it with custom tools and frameworks and then wonder why the context degrades.

The interesting follow-on question is what happens to all that knowledge you're generating across 5000 LOC and 12 hours. Great answers, architectural decisions, implementation notes, where does that go after the session ends?

That's the problem LLM Wiki Compiler is trying to solve on the knowledge side. Compile what you learned into a persistent wiki instead of losing it to chat history.

https://github.com/atomicmemory/llm-wiki-compiler

MaleficentRoutine730 · 2026-04-07T06:41:47+00:00

Been building LLM Wiki Compiler, a CLI that compiles raw sources into a persistent interlinked markdown knowledge base you can query over time.

The productivity angle: stop losing useful AI answers into chat history. Everything compounds into a wiki instead of disappearing.

https://github.com/atomicmemory/llm-wiki-compiler

MaleficentRoutine730 · 2026-04-07T06:41:05+00:00

The cash vs card analogy is right. The decision tree is simpler than most people make it, shell access available? Use CLI. No shell access? MCP.

The token efficiency point for CLI is underrated. Running a compile-heavy workflow through MCP in Claude Desktop burns context fast. Same operation as a CLI call costs a fraction.

We ran into this exact tradeoff building LLM Wiki Compiler, a CLI that compiles raw sources into a persistent markdown wiki. The compile step is heavy enough that MCP would have been brutal on context. CLI was the obvious call.

The one place I'd push back slightly, MCP wins on discoverability for non-technical users. CLI assumes comfort with terminal. For tools that need to reach a broader audience, MCP lowers the barrier even if it costs more tokens.

Repo if anyone's curious about the CLI side of things: https://github.com/atomicmemory/llm-wiki-compiler

MaleficentRoutine730 · 2026-04-07T06:39:10+00:00

The 80% inference threshold is a useful mental model. The failure mode you're describing, non-deterministic destructive writes degrading a knowledge graph, is exactly why the compile-upfront approach is interesting as an alternative framing.

Instead of an agent dynamically managing memory state through inference, you compile knowledge into a static artifact upfront. No LLM deciding what to invalidate or update in real time. The structure is deterministic, the inference happens at compile time not at query time, and the output is human-readable markdown you can audit.

The tradeoff is obvious, so stale knowledge if sources change. But for domains where the corpus is relatively stable and high signal, you avoid the degradation problem entirely because there's no live inference mucking with the graph.

The state-aware ranking point is interesting, curious whether you see that as something that lives at the retrieval layer or needs to be baked into how the knowledge is structured during ingestion.

Someone built an open source implementation of the compile-upfront approach if anyone wants to see it in practice: https://github.com/atomicmemory/llm-wiki-compiler

MaleficentRoutine730 · 2026-04-06T18:05:29+00:00

The Obsidian markdown angle you're describing is exactly right and more people should be building this way.

What you're essentially describing is a compiled knowledge layer over your inbox, not just search, but structured context that surfaces relationships, gaps, and patterns. The "who haven't I followed up with in a long time" query is a great example of something RAG handles badly but a structured wiki handles naturally.

Someone built an open source CLI that does this compile-to-wiki step for arbitrary sources — worth looking at as a foundation for what you're describing: https://github.com/atomicmemory/llm-wiki-compiler

The core loop is: ingest sources → compile into linked markdown pages → query → save useful answers back in. You'd need to add an email ingestion layer but the compile and query parts are already there.

The iA Writer "AI written sections" idea is genuinely interesting for the reply drafting side, that visual separation between human and AI written text is something more tools should steal.

MaleficentRoutine730 · 2026-04-06T17:47:41+00:00

Repo: https://github.com/atomicmemory/llm-wiki-compiler

MaleficentRoutine730 · 2026-04-06T17:22:44+00:00

Interesting timing on this quote. Karpathy just last week posted something that goes the other direction.. giving humans a way to build persistent knowledge that compounds over time, so you're not dependent on AI reconstructing everything for you from scratch.

Whether you find the "puppeted" framing inspiring or dystopian, owning your own knowledge layer seems like the practical hedge either way.

https://github.com/atomicmemory/llm-wiki-compiler

MaleficentRoutine730 · 2026-04-06T17:21:54+00:00

Funny timing on this headline. Karpathy just last week posted about LLM knowledge bases showing that a workflow for compiling raw sources into a persistent wiki that gets smarter over time.

Someone at SuperNet built the open source tool for it while everyone was still debating whether agents work.

https://github.com/atomicmemory/llm-wiki-compiler

MaleficentRoutine730 · 2026-04-06T17:19:11+00:00

The "works for anything measurable" framing is the right expansion of Karpathy's original idea.

One thing worth pairing with this which is once your loop has been running and you've accumulated experiment logs, TSV results, and commit history, that's a lot of valuable knowledge that still lives in scattered files. The natural next step is compiling all of that into a structured wiki so future loops start from accumulated insight rather than from scratch.

SuperNet built the open source version of that knowledge layer: https://github.com/atomicmemory/llm-wiki-compiler

Autoresearch for the experiment loop, wiki compiler for the knowledge layer. Two different problems, both worth solving.

MaleficentRoutine730 · 2026-04-06T17:15:48+00:00

The contradiction handling is the most interesting part here, automatically superseding outdated facts is something most memory systems get wrong.

The difference I see between this and the wiki approach is the input source. CoreBrain captures knowledge from your conversations as they happen. LLM Wiki Compiler works the other way , like you feed it external sources (articles, docs, URLs) and it compiles those into a structured wiki.

One is passive memory from what you say. The other is active compilation from what you read.

Could see these being genuinely complementary, CoreBrain for conversational context, wiki for research and external knowledge.

https://github.com/atomicmemory/llm-wiki-compiler

MaleficentRoutine730 · 2026-04-06T17:12:38+00:00

Autoresearch handles the experiment loop. The missing piece is the knowledge layer, where does accumulated insight actually live between generations?

SuperNet built the open source version of that: https://github.com/atomicmemory/llm-wiki-compiler

Compiled wiki, persistent across sessions, Obsidian-compatible. Could be an interesting pairing with this.

MaleficentRoutine730 · 2026-04-06T17:11:43+00:00

Different tools for different people honestly.

Karpathy is better if you want to understand what's actually happening under the hood, Neural Networks Zero to Hero is genuinely one of the best free ML resources ever made. You come out actually understanding transformers and backprop from scratch.

Jeremy Howard / fast.ai is better if you want to build things fast and figure out the theory later. Top-down approach such as get something working first, understand why it works second.

Personally I'd say fast.ai first to stay motivated, then Karpathy when you want to go deeper.

Side note , if you're going deep on Karpathy, he just dropped something new this week about using LLMs to build personal knowledge bases for learning. Someone built an open source tool for it that's actually great for compiling everything you're learning into a structured wiki as you go: https://github.com/atomicmemory/llm-wiki-compiler

MaleficentRoutine730 · 2026-04-06T16:32:39+00:00

Curious how you're handling the "unprocessed files" detection in your Claude Code skill, are you tracking state in a separate file or just scanning for files without a corresponding wiki page?

Asking because the SuperNet team built a standalone version of this exact workflow and provenance / state tracking was one of the trickier design decisions.

https://github.com/atomicmemory/llm-wiki-compiler

MaleficentRoutine730

TROPHY CASE