Connect, share wins, swap ideas, and chill with fellow community members

Member Lounge

A field guide to the five thinking-machines behind every onchain mechanic — and a Claude skill that runs the diagnosis on your own repo. With a full worked example: the skill run on Arc's own whitepaper and litepaper.

 by the philosopher Fernando Wirtz, riffing on Yuk Hui's new book 

Kant Machine: Critical Philosophy after AI

. The premise sounds academic and turns out to be the most useful product lens I've picked up all year: 

a machine-learning architecture is an engineering answer to an old question — 

 That's why you can map classical philosophers onto machines without it being a cute analogy. Both are answers to the same problem, built in different materials.

Hui sorts AI into Cartesian, Humean, and Kantian machines. Wirtz pushes it into politics and desire and adds two more: the 

 machine (mimetic desire — and yes, the Thiel/Karp/Girard-at-Stanford lineage is the spicy subplot). Five machines.

Here's the builder's version of the question. Not 

"which machine am I actually running — and is it the one I think I built?"

 Because the gap between those two is where protocols die.

Read that table twice. Almost everything we ship is a 

 of these, not a single one — and the trouble is always the layer you didn't know was load-bearing.

The move that matters: find the hidden machine

The one question the whole framework exists to ask:

Which machine is actually running under the one they think they built?

a Humean intention masking a Girardian engine.

 You tell yourself "we reward usage" (Humean — frequency, volume, your own history). What you actually built rewards 

 (Girardian — status, imitation). Both pump the same dashboard up and to the right, right up until the Girardian failure mode hits and the mercenaries leave for a shinier tier.

Two tests cut through it, and both are code-level enough to be honest:

 desire — like-counts, "N people aped this", rank-vs-peers, TVL others can see. Open the actual reward/ranking function. If it only consumes the user's own data, it's Humean even when engagement is feral. If it imports the crowd's behavior as signal, the Girardian layer is real.

 Kill the leaderboard, hide everyone's rank. Whatever survives was Humean. Whatever collapses was Girardian all along.

 lives, and it's not decoration. Mimetic desire is 

 — it feeds back on itself. My want grows because yours grows because mine grows. Wirtz points at Schelling: in a standoff, the one who convinces you he'll jump off the cliff wins — but when 

 parties are "crazy," escalation to mutual destruction is the only equilibrium. That's a points war. That's two L2s torching emissions at each other. That's a memecoin: value purely because others want it, and the rug is the 

 — the crowd sacrifices the bagholder and re-unifies around the next ticker. Girard described that mechanism 50 years before we automated it.

Why a builder should care: you can be wrong about your own product

Here's the uncomfortable part. The hidden machine is invisible 

. You wrote the code; you also wrote the story you tell about the code. They diverge silently.

Take a feature I literally had on a branch: 

. Sounds like a Humean loyalty mechanic — trade more, pay less. Run the lens:

 VIP tier wouldn't drive the same behavior. So the real engine is positional, not volumetric.

 distribution. Cuteness makes the badge screenshottable — a desire-triangulation skin doing the mimetic spread the fee math can't.

So the "loyalty optimizer" was a status engine wearing a loyalty costume. And the 

 cutoff is Cartesian and wash-trade-farmable. Fix: derive the tier from 

 liquidity, tenure, retention, counterparty quality — there's no static number left to game.

or revocation when someone Sybils it. Without it, the first competent farmer 

Pure Girardian retention → mercenary churn.

 Fix the way the article does: use the mimetic pull for 

 good the user keeps regardless of rank (a vested rebate, real tenure, governance weight). That's the difference between a memecoin and a brand.

That diagnosis took twenty minutes. It would have taken three months and a dead incentive budget to learn it the other way.

This is the same thread I've been pulling in the member lounge, just named properly now:

Onchain Cash Will Be King — StableFX on Arc

 machine we have — price as the input that translates desire into quantity. Honest, durable, and exactly why it's a 

: the whole "where does custody sit" question 

 question — who holds the exception, and how do you keep it from becoming the rule.

After the Arc launch, the next step is shhhhh

 of the Girardian feed — you can't triangulate transaction amounts you can't see.

: that thread about the mental toll of VC breakout narratives? That's mimetic desire pointed at 

 The burnout loop and the memecoin loop are the 

 — desire borrowed from the crowd, escalating until something breaks. Naming it is the first step to staying outside it.

Applied AI:  turning the lens into a tool you can run

Here's the part that closes the loop on "AI knowledge applied to mechanics." A framework you have to 

 to use is a framework you'll skip at 3 a.m. when the incentive design is due. So I encoded it as a 

 — a reusable thinking instrument that decomposes any product, contract, or growth loop into its machine-stack, names the hidden machine, traces the failure loop, and prescribes the recomposition.

 folder into your Claude Code skills directory (or upload the 

 artifact), and it triggers when you ask things like:

"Decompose our points program into its machine stack — what's the hidden machine?"

"Is this fee tier Humean or Girardian? Would it survive if rank were a different treshold?"

"Why does our leaderboard churn, and how do I make retention non-positional?"

"Review the behavioral logic of a stablecoin with a freeze function."

It returns a stack inventory, the intended-vs-actual gap, the failure loop, the missing machines (each flagged as a concrete vulnerability), and an ordered set of fixes mapped to real surfaces. I built it against the exact over-correction it's prone to — it will 

 cry "Girardian" at an honest Humean optimizer, because the first thing it checks is whose data is in the function.

🧪 The worked example: running the lens on Arc itself

So let's actually do it — on the most load-bearing object in this whole community. I fed the skill Circle's two primary docs — the 

 — and asked it the only question that matters: 

(The caveat Circle would want me to make, and I'll happily make: ARC is exploratory and unlaunched — "subject to change." This is an analysis of the design as written, not a claim about a shipped token.)

Arc is the obvious stress test. It's the "Economic OS" L1 where USDC is gas: 10B ARC, a decaying 2–3% inflation to validators/stakers, every protocol fee auto-converted to ARC at settlement and split between distribution and burn, staking rewards proportional to stake, gas discounts that scale with your volume, stake-weighted governance over fees/inflation/burn. Read the marketing and it's a clean Humean flywheel — activity funds security funds activity, "converting the participants who use Arc into the participants who sustain it." Five reinforcing functions, all measuring throughput.

And there's the hidden machine. Arc narrates itself as Humean, but the load-bearing layer is 

 What institutions are actually buying isn't the flywheel — it's a known, accountable sovereign who can freeze, screen, and intervene. The whitepaper's own pitch — "the conditions under which institutions can rely on Arc" — is the decisionist guarantee, restated as a feature. Same issuer-sovereign lineage as the USDC freeze function. "Code is law" is the alibi; the freeze is the soul.

Now the part I want to flag, because it's the discipline check on the whole framework: 

 There are no leaderboards, no VIP badges, no points, no status tiers — and the gas discount keys off your own volume, not your rank. Run the privacy test: a secret gas discount still works. So it's Humean, full stop. The only mimetic vector is 

 the protocol, at the token-market layer — stake-because-others-stake, the reflexive "signal confidence by staking" loop. Latent, not engineered. The design is right not to import it, and a tool worth trusting has to be able to say "this honest Humean optimizer is exactly what it claims" instead of forcing the spicy answer.

So how does this Arc stack die? Three loops, in order of likelihood:

 "Authority expands with readiness" is the classic decisionist tell — the override is promised as temporary. Until it actually retracts, every validator and holder is provisional on Circle's continued forbearance. That's the decisionist failure mode straight off the table above.

The bootstrap pays for measured volume before it can tell real from farmed.

 2–3% inflation rewards stakers before real fee revenue exists, so it subsidizes whatever 

 like activity. 244M testnet transactions — how many are economic events? Pure Humean self-consumption: it optimizes the only thing it can see.

 "Inflation neutrality" is a fixed curve assuming fee volume arrives on schedule. If adoption lags, the rulebook keeps issuing into a supply with no offsetting burn — it can't reason about the slow-growth context it was never coded for.

And the recomposition writes itself once the stack is named:

Make the Kantian layer real before the decisionist one retracts.

 Derive validator standing and reward weight from realized behavior — uptime, real-fee generation, counterparty quality — not raw stake. Otherwise governance is a quantity vote (25% Circle + whales) wearing a constitution, and the "configurable" params just ossify into a new Cartesian rulebook.

Peg rewards and burn to economically meaningful fees, not transaction count,

 so inflation can't subsidize wash volume. (A Kantian constraint on a Humean engine — not more data, better-shaped data.)

Name and bound the decisionist layer instead of dissolving it.

 the product. Publish the exception surface — what Circle can freeze, by what process, with what measurable sunset — so "authority expands with readiness" becomes a commitment and not a vibe. A decisionist machine that admits it is one is far healthier than one wearing a permissionless mask.

The one-liner the skill spat out, which I think is just correct:

ARC is narrated as a Humean flywheel, is in practice a decisionist issuer-sovereign with a Humean reward engine bolted on, and aspires to a Kantian governance layer it hasn't built yet. Its real risk was never mimesis — it's the un-sunset exception and a bootstrap that pays for volume it can't yet verify.

 than most of what we ship: its retention moat is compliance and Circle integration — non-portable in a way a memecoin badge never is. No status engine hiding in a loyalty program or promises. For once.

Such an interesting output! That's the whole point of having the tool. It found the load-bearing layer, and it knew when to keep its mouth shut.

Run it on something you're shipping this week. Not the thing you're proud of — the incentive you're slightly unsure about. Then tell me, in this board, 

 I'd bet a round of cortados that at least a third of us discover we built a status engine and called it a loyalty program.

Build deliberately. Compose the stack on purpose. And every so often, ask the badge whether it would still work in the dark.

 — the ARC token whitepaper (May 2026): 

(ARC is exploratory and unlaunched; figures and mechanics above are read from these documents and are subject to change per Circle.)

Credit where it's due: the three-machine core is 

, Kant Machine: Critical Philosophy after AI (2026). The decisionist and Girardian extensions — and the name "cyber-kantics" — come from 

"The Philosophy Behind Artificial Intelligence: Cyber-Kantianism and Dark Girardianism," 421.news, 2026

. Schmitt and Girard did the heavy lifting decades ago. I just wired it into a tool. The skill itself is MIT and open: 

The Hidden Machine: which philosophy is your protocol actually running? An Arc Tokenomics cyber-kantic analysis  🚬🥃

Home

Forum

Events

Content

Courses

People

Contributors

Albums

Groups

Chat

Channels

Not being used

Help

Join the global network of builders developing the Economic OS for the internet. We’re reimagining how value moves, creating the tools that make the economy work for everyone.

Arc House

Profession

Join a global network of builders developing the Economic OS for the internet. We’re reimagining how value moves, creating the tools that make that economy work for everyone. 

Arc House | Build the economic OS for the internet with us

Copyright

Terms of Service

Privacy

Code of Conduct

Your Privacy Choices

It looks like there is no account associated with the email you provided. The event is for members only. Please complete the application to join our community first.

Thank you for your interest in joining us

Thanks for your interest in joining the event. However, your account is still pending. Once it's approved, you'll be able to register for the event. Please contact us via noreply@arc.network if you need support.

Pending Approval

Login to the The Arc Community Hub community to connect with others, attend community events, and more!

Login or Sign Up for even more

To unlock all parts of the community complete your profile using verifiable and real information.

Hey, complete your profile

It looks like there is no account associated with the email you provided. Please complete the application to join our community.

Thank you for your interest in joining Arc House.

Thanks for your interest in joining Arc House. We will review your request shortly and email you once it's approved. Meanwhile, please feel free to contact us via noreply@arc.network for any questions.

Accounts are unapproved when profile information cannot be verified or when activity patterns indicate spam, inorganic participation, or behavior that undermines trust in the program.

To strengthen your profile for future consideration, sign in with a verified LinkedIn account, use real and current profile information, and participate constructively in other community spaces.

Commercial customers should raise concerns through their support channel.

https://www.arc.network/community-guidelines