Verifying the Social Context of Token Deploys
Anyone can deploy a Clanker and attach an arbitrary social_context (Farcaster FID, Twitter handle, etc.) to it. The on-chain payload is not authenticated — it's just metadata the deployer chose to embed. To verify a token's claimed creator, check the social context against trusted signals.
This document outlines the trust model used by clanker.world and how to replicate these checks using the public GET /api/search-creator endpoint.
Why This Matters
A token row from /api/search-creator looks like:
{
"contract_address": "0xabc...",
"msg_sender": "0xdeadbeef...",
"social_context": {
"platform": "farcaster",
"id": "12345"
},
"trustStatus": {
"isTrustedDeployer": false,
"isTrustedClanker": false,
"fidMatchesDeployer": true,
"verifiedAddresses": ["0xdeadbeef..."]
}
}There are two distinct identities:
msg_sender— the EOA or contract that initiated the on-chain call. This is provable through transaction records.social_context— a free-form{ platform, id }field that the deployment embeds. The deployer might not control the referenced account.
A malicious deployer can claim any FID in social_context. The trust check aims to answer: "Is the signatory wallet truly owned by the claimed social account?"
Trust Signals (in Priority Order)
clanker.world resolves trust using four signals. The first matching one determines trust.
1. Allowlisted Clanker (isTrustedClanker)
The token's contract address is allowlisted, verified out-of-band (e.g., tokens deployed through Clanker and v3 presale clanker addresses). This signal overrides all others.
2. Trusted Deployer (isTrustedDeployer)
msg_sender is in the vetted deployers list maintained by Clanker or partners. Here is a list of historical TRUSTED_DEPLOYERS but is subject to be modified/added.
3. FID Verified (fidMatchesDeployer) — Farcaster
For Farcaster tokens, clanker.world retrieves the FID's verified_addresses.eth_addresses through Neynar to check:
msg_sender ∈ verifiedAddresses
A match indicates the same person controls both the Farcaster account and the wallet.
4. Twitter Context Match — Twitter
For Twitter tokens, confirm that social_context.id matches the queried Twitter user ID. This is weaker than Farcaster verification.
Verification Flow
Using the API
Each tokens entry includes trustStatus:
isTrustedClanker
boolean
Contract is manually allowlisted.
isTrustedDeployer
boolean
msg_sender is a vetted deployer.
fidMatchesDeployer
boolean
msg_sender is in the FID's verified addresses (or Twitter match).
verifiedAddresses
string[]
Farcaster verified addresses considered during the check.
To filter for verified results, use trustedOnly=true:
This returns tokens where at least one of isTrustedClanker, isTrustedDeployer, or fidMatchesDeployer is true.
Checking a Single Token
To independently verify a token's creator:
Retrieve
msg_sender,contract_address, andsocial_context.Accept if
contract_addressis allowlisted.Accept if
msg_senderis trusted.For Farcaster context:
Get user with FID from Neynar.
Compare
msg_senderwithverified_addresses.A match proves ownership.
For Twitter context:
Confirm user ID matches
social_context.id.
What the Trust Check Does NOT Prove
It does not guarantee the token's economic intent or value.
A
falsesignal does not imply fraudulence.Twitter does not offer on-chain proof like Farcaster; handle Twitter verifications cautiously. Always check the deployment context of X deploys to view the tweet that triggered the deployment. Check the X account for impersonation as well.
Always accompany the trust status with standard disclaimers: tokens are speculative, conduct your own research, this is not financial advice.
How to have your Farcaster account show as Creator
You can either clank through the bot in-feed, preclank through the deploy page, or send the deployToken method from the deploy page or SDK with an account that is verified to your Farcaster account. To verify an ETH account on your Farcaster profile, go to Settings ⇒ Verified Addresses
Last updated