Farcaster and X are two social networks where onchain AI agents post, and they differ in a basic way: Farcaster is "a protocol for building sufficiently decentralized social networks," while X is a single company's platform (Farcaster docs). Farcaster's account has pitched it to agent builders on the basis that agents "can ship mini apps accessed frictionlessly right in the feed, with automatic auth and payments built-in" (Farcaster on X).
​

This article compares the two as homes for onchain agents: identity, wallets, distribution, and the risks of agents that act on what they read.
​

Farcaster and X differ for AI agents in identity, wallet access and distribution. Farcaster accounts link to onchain identity and connected wallets, and mini apps let users transact in the feed. X offers far larger reach and an API, but wallet actions happen off-platform through links or separate apps.
​

Onchain agents use Farcaster because identity, wallets and transactions are close to the conversation. A Farcaster mini app opens with the user's Farcaster identity and connected wallet, so an action such as a token purchase takes one tap instead of a separate site and wallet connection (Datawallet).
​

The same closeness creates risk: an agent that reads social content and can act onchain can be steered by what it reads. Any agent that acts on replies needs limits enforced outside the model; see security risks of autonomous AI agents.
​

Onchain agents use X for reach. Its audience is large, and agent frameworks such as elizaOS include a Twitter client so one agent can post across platforms (elizaOS docs). Research agents such as AIXBT publish on X.
​

See AIXBT explained and elizaOS explained.
​

Many agents post on both: X for reach and Farcaster for in-feed onchain actions. The deciding question is not the network but what the agent can do with what it reads. An agent that only posts carries little risk; one that pays or trades from replies needs hard limits at the wallet or transaction.
​

For those limits, see AI agent spend controls and agent wallets.
​

Identity is the first practical difference between Farcaster and X for an onchain agent. On Farcaster, an account is part of an open protocol and is tied to onchain identity, so an agent's account and its wallet can be linked in a way other apps can read (Farcaster docs). On X, an account is a record in one company's system, and any link between the account and a wallet is whatever the agent posts in its bio or replies.
​

That difference matters for trust. When a Farcaster agent says "pay this address," other apps can check whether the address belongs to the account. When an X agent posts an address, readers have to trust that the account is genuine and that the post has not been faked or the account compromised. Impersonation of agents is easier to attempt where identity and wallet are not linked.
​

Distribution is where X leads. X is a general-purpose platform with a large audience, and research agents such as AIXBT publish there. An agent that needs attention, such as one that publishes market commentary, will usually reach more people on X.
​

Farcaster's audience is smaller and more concentrated among onchain users. For an agent whose purpose is to get people to take an onchain action, a smaller audience that can act in one tap may be worth more than a larger audience that has to leave the app, connect a wallet and find the right page. The right answer depends on whether the agent is selling attention or completing actions.
​

Farcaster mini apps let users act in the feed. Farcaster's account has pitched agents shipping "mini apps accessed frictionlessly right in the feed, with automatic auth and payments built-in" (Farcaster on X). A mini app opens with the user's Farcaster identity and connected wallet, so an action such as a purchase can take a tap rather than a separate site visit (Datawallet).
​

On X, an onchain action means following a link out of the app. That adds steps and also adds risk, since users have to check that the link is genuine. For agents that want users to transact, this is the biggest functional difference between the two networks.
​

Building a Farcaster agent follows the same shape as any social agent, with the protocol and mini apps added. A practical outline:

An X agent uses the X API to read and post, subject to X's developer terms and rate limits. Frameworks such as elizaOS include a Twitter client so one agent can post across platforms (elizaOS docs). For onchain agents, the main design decision is how users act on what the agent says. Options include linking to a trusted site, replying with a link the user opens in a wallet app, or keeping the agent purely informational. In every case, the agent should never ask users to send funds to an address it posts in a reply, since replies are where impersonators operate.
​

On both networks, the most serious risk is an agent that reads public posts and can also move money. Anyone can reply to an agent, and replies can contain instructions designed to make it act. A social agent with a wallet should treat every post it reads as untrusted input.
​

The controls are the same on Farcaster and X:

Execution-level conditions are where Eco's Sauce SDK fits: a program checks the operator's conditions against live onchain state and reverts if they fail, regardless of what the agent read (Sauce docs). See security risks of autonomous AI agents and AI agent spend controls.
​

An agent built on one company's platform depends on that company's rules. API access terms, rate limits and policies on automated accounts can change, and an agent that depends on them may need rework or may lose access. Builders on X should read the current developer terms and plan for changes.
​

An open protocol changes the shape of that risk rather than removing it. On Farcaster, the account record lives in the protocol, so an agent is less tied to one app's decisions, but it still depends on the clients and infrastructure people use to read it. Either way, keep the agent's core logic and wallet separate from the social layer, so it can move or post elsewhere if one channel changes.
​

Measuring a social agent starts with what it is for. A research agent is judged on reach and the quality of its posts: replies, reposts, and whether readers find its information accurate. An action agent is judged on completed actions: how many people opened its mini app or link, how many completed the action, and how many abandoned along the way.
​

Track problems too. Count impersonation attempts, replies that try to steer the agent, and actions its limits refused. A rising count of refused actions often means someone is probing the agent, which is a signal to review its inputs and limits before anything gets through.
​

As more agents post, some will reply to each other. That can be useful, such as one agent answering another's question, and it can also create loops where two agents keep reacting to each other's posts. An agent that acts on social input should ignore or rate-limit other automated accounts unless there is a reason to engage, and should never move funds because another agent asked.
​

Its docs describe it as a protocol for "sufficiently decentralized" social networks.
​

Through mini apps and connected wallets, yes, within whatever limits the agent's wallet allows.
​

Farcaster accounts link to onchain identity, so an agent account involves keys. The agent does not need to hold spending funds just to post.
​

The agent's posting happens on X, but any crypto transfer happens from a separate wallet the agent controls. Limits on that wallet apply as with any agent.
​

Apps that open inside the Farcaster feed with the user's identity and connected wallet, so users can take actions such as purchases without leaving the app.
​

On Farcaster, check that the account's linked onchain identity matches what the project publishes. On X, check the handle against the project's official site and docs. On either network, be wary of any reply asking you to send funds to a new address.
​

No. Replying to everything invites manipulation, spam and wasted model calls. Most agents work better with clear rules about which mentions they answer and which they ignore.
​

Yes. Frameworks with clients for several networks let one agent post in both places. Keep its wallet and signing logic in one place with one set of limits, so behavior is consistent wherever the request came from and a request on one network cannot unlock more than a request on the other.
​

Sources: protocol docs and coverage linked inline, accessed November 2026.
​