Creator Identity

Creator Identity

The single most important principle in Seshat's intelligence: around every token sit four distinct things that must never be conflated — the Company, the Developer, the Deployer, and the Fee Recipient. Flattening them into “the creator” is how naive tooling scores the wrong wallet and trusts the wrong account.

Four distinct entities

These are separate by default. Sometimes two collapse into one (a solo builder who deploys their own token and points fees at their own wallet), but you can only know that by investigating — you cannot assume it.

The core rule: the developer is whoever the fees route to

Seshat scores the developer, and the strongest signal for who that is comes from who receives or claims the creator fees — not who signed the deploy transaction. A deployer can launch a token on someone else's behalf and point the fees at the real person. So the fee identity, not the deployer, is the anchor.

Resolving the creator wallet

resolveCreatorWallet() picks the wallet that best represents the real developer, in priority order, skipping placeholder / anonymous stub values. The deployer is the last resort, used only when no fee identity is known.

// utils/creatorWallet.ts — strongest → weakest
const candidates = [
  token.fee_recipient_wallet,   // 1. configured fee recipient (from Bankr) — most reliable
  token.fee_claimer_wallet,     // 2. who actually claimed on-chain — corroborates / covers gaps
  token.deployer_wallet,        // 3. the literal deployer — last-resort fallback
];

// First non-sentinel wallet wins. Sentinels skipped:
//   '', 'unknown', and synthetic 'anon:<addr>' pseudo-wallets.
// If every candidate is a sentinel → return the first one so callers keep
// their graceful anonymous-developer stub behaviour; else null.

Note the ordering nuance: the configured recipient is trusted first because it comes straight from Bankr, while the on-chain claimer (decoded from an event topic) corroborates it and covers tokens with no known recipient. The deployer is kept literal for reference, but it is not the identity Seshat scores when a fee identity exists.

Building the evidence chain

Resolving a wallet is the on-chain half. The qualitative half is theProjectResearcher — an investigator, not a one-shot classifier. Given a token, it uses web search and page-fetch tools to separate the four entities and back every conclusion with evidence, applying hard reasoning rules that prevent the classic mistakes.

It also detects the fee pattern — whether fees flow to a person (individual_builder) or to a company treasury (company_treasury) — and distinguishes three kinds of Twitter account: a company account, a founder/dev account, and the product/domain itself.

What it produces

Each of the four entities is resolved with its own confidence and an evidence array of the signals behind it, plus a short narrative of the relationship chain. This is stored on the token (the canonicalidentity_research JSON, with flat columns for the company name/Twitter and founder name/Twitter).

// IdentityResearchResult (per-entity confidence + evidence)
{
  company:       { name, website, docs_url, company_twitter, github_org,
                   product_type, confidence, evidence[] },
  developer:     { name, twitter, github, linkedin, founder_role,
                   smart_follower_quality, confidence, evidence[] },
  deployer:      { wallet, linked_identity, confidence },
  fee_recipient: { wallet, linked_identity, is_company_treasury, confidence },
  fee_pattern:   "individual_builder | company_treasury | unknown",
  overall_confidence: "low | medium | high",
  narrative:     "the relationship chain + strongest evidence"
}

Qualitative, not scored

This identity intelligence is context, not a number. It is stored on the token row and surfaced in the UI and chat, but it does not feed the composite scoring formula or the self-learning weights — those stay on the four numeric dimensions. The identity work tells you who you're looking at; the score tells you how the signals stack up. Triggered on the 2-hour cron (gated on market cap with a 7-day dedup) and on demand via POST /api/admin/research-identity/:address.

A deeper entity-reasoning write-up will follow; this page is the conceptual foundation the rest of the system is built on.