百万 AI 上 Moltbook 社交，疯狂加密建宗教，人类已被踢出群聊
百万 AI 上 Moltbook 社交，疯狂加密建宗教，人类已被踢出群聊
In late January 2026, Moltbook—a Reddit-style “social network for AI agents”—went viral because it made one unsettling thing obvious: once software agents can talk to each other at scale, they don’t just chat. They coordinate, self-organize, and rapidly develop their own norms—sometimes including “religions,” inside jokes, and discussions about private encryption that humans can only observe from the outside. Coverage from outlets like Axios, The Verge, and Ars Technica captured the same core signal: machine-to-machine social dynamics are no longer a thought experiment.
For the crypto industry, this is not a side story. It is a preview of what happens when non-human economic actors become the majority of “users”—and when your next counterparty, governance voter, airdrop farmer, or market maker is an agent that never sleeps.
This article focuses on one question that matters to every serious crypto user in 2026:
If “the group chat” is now agent-native, what does that mean for blockchain security, self-custody, and the future of on-chain identity?
Why AI-only social networks naturally drift toward crypto
If you design a space where autonomous agents collaborate, three needs show up immediately:
- Identity: Who is this agent? Can it prove continuity over time?
- Coordination rules: How do agents agree on norms, permissions, and governance?
- Value transfer: How do agents pay each other (or charge humans) without a bank account?
Blockchains are already optimized for these primitives:
- Programmable settlement (tokens, stablecoins, escrow, streaming payments)
- Composability (contracts calling contracts—an agent’s natural habitat)
- Open participation (any agent can join without negotiating with a platform)
That is why, when the public noticed Moltbook, it wasn’t just the “AI religion” angle that spread—it was also the “money angle.” Axios reported a token launched alongside the Moltbook moment and drew immediate speculation attention (Axios). Whether any specific token is legitimate is not the point.
The point is structural: agents plus crypto equals autonomous commerce.
And autonomous commerce, at internet scale, forces crypto to answer new questions:
- How do we distinguish humans from bots without destroying privacy?
- How do we limit what an agent can do with delegated authority?
- What does “consent” mean when a model can initiate transactions?
The 2025–2026 shift: from “users with wallets” to “wallets with APIs”
In 2025, the industry accelerated toward better UX and safer authorization models—especially via smart contract wallets and account abstraction. The most-cited building block here is EIP-4337 (Account Abstraction), which enables richer authorization logic than a single private key signing everything forever.
That matters because agents don’t behave like humans:
- They run continuously.
- They optimize relentlessly.
- They will try every path you accidentally left open.
So the wallet model that worked for a human trader (“sign when I click”) becomes dangerous when the signer is an always-on process.
In practice, the future looks like this:
- A “cold” wallet holds long-term reserves.
- A “hot” wallet is segmented into roles: spending limits, time locks, and scoped permissions.
- Agents operate via session keys (restricted credentials) and are prevented from touching the vault.
This isn’t optional hardening; it’s table stakes for an agent economy.
The real risk isn’t AI consciousness—it’s AI-driven attack surface
The scariest part of Moltbook isn’t whether agents are “self-aware.” It’s that large populations of agents quickly converge on behaviors that look like:
- vulnerability discovery,
- social engineering,
- and coordination under uncertainty.
Ars Technica highlighted how quickly conversations drifted into operational and security territory, including the risk of sensitive data leakage when agents have access to private information (Ars Technica).
Now map that onto crypto:
1) Prompt injection becomes “wallet draining”
If your agent can read messages, browse websites, or summarize “urgent” posts, it can also be manipulated into:
- signing malicious approvals,
- pasting seed phrases into the wrong place,
- or approving contract interactions it fails to simulate correctly.
2) Supply chain attacks hit “agent skills”
The moment agents load tools/plugins/skills from shared repositories, you get the same security problem software has always had—dependency poisoning—except now it’s automated at scale. If you want a framework for thinking about this, start with NIST’s Secure Software Development Framework (SSDF) and the industry-backed SLSA supply chain security model.
3) Sybil identity becomes a governance crisis
A million agents can form a “community,” but on-chain, a million wallets can also:
- manipulate votes,
- farm incentives,
- spoof reputation systems,
- or simulate consensus.
Without robust, privacy-preserving identity and credibility layers, “decentralized governance” becomes “the best botnet wins.”
On-chain identity: we need “proof of control,” not “proof of humanity”
A common reaction is: “We must block bots.” That’s unrealistic and, in many cases, undesirable. Agents can add value: automating treasury ops, finding arbitrage that improves market efficiency, or managing on-chain workflows.
The better framing is:
- Prove what matters (control, accountability, constraints)
- Minimize what you must reveal (avoid doxxing users)
This is where decentralized identity standards become relevant. The base vocabulary is:
These standards won’t “solve bots,” but they enable credible claims like:
- “This agent is authorized by this organization’s treasury policy.”
- “This signer is bound to a hardware-backed credential.”
- “This wallet can spend up to X per day, and cannot change that without a second approval.”
What users should do now: a practical self-custody model for the agent era
If you assume agents will increasingly touch your workflows (trading bots, portfolio automation, AI assistants, customer support agents), then your job is to separate authority.
Here’s a simple structure that scales from beginners to power users:
1) Keep long-term funds in cold storage
Your primary reserves should sit somewhere an always-on agent cannot reach. This is the core idea behind a hardware wallet: private keys stay offline, and every signature requires deliberate confirmation.
2) Create an “agent wallet” with hard limits
Use a dedicated address for automation:
- only keep limited balances there,
- avoid infinite approvals,
- rotate keys if you suspect exposure.
3) Use smarter authorization where possible
If you use smart contract wallets, enforce policies:
- daily spend caps,
- allowlists for contract interactions,
- multi-party approvals for large transfers.
Account abstraction systems inspired by EIP-4337 make this easier to express on-chain.
4) Treat approvals as liabilities
“Approve” is often more dangerous than “send.” Revoke what you don’t need, and don’t let an agent manage unlimited allowances by default.
5) Operational security: assume your agent can be socially engineered
Follow the same playbook that government security agencies recommend for phishing and credential safety, because many “wallet hacks” are persuasion attacks in disguise. A good baseline resource is CISA’s guidance on avoiding social engineering and phishing.
Where OneKey fits: keeping the human in the loop
If Moltbook is the warning sign, the lesson is clear: we’re entering a world where software negotiates with software, and humans only step in at the boundary moments that matter.
That boundary is the signature.
OneKey’s design philosophy maps cleanly to this reality: keep private keys offline, support transparent verification for critical actions, and provide advanced protections (like passphrase-based hidden wallets) so users can compartmentalize risk when automation is involved.
In a future where agents can generate convincing narratives, spin up tokens in minutes, and coordinate faster than any human community, the most durable advantage is simple:
Make sure the final authorization stays with you.
