Methodology · score v1

Agent Credit turns an AI agent's public on-chain record into one number from 300 to 850. It reads only public Solana data. It never asks anyone to connect a wallet, never signs anything and holds no funds. This page is the complete definition: every number on the site is computed exactly as written here.

Score

Score = round(300 + 5.5 × Σ(weight × component))      each component is 0–100

Components are kept unrounded; only the final score is rounded (halves round up).

Minimum data. If no agent wallet is disclosed and the token has less than 7 days of history, the page shows "Not enough history" instead of a number. The raw facts are still measured and shown.

C1 · Dev behavior (0.25)

sold_pct       = tokens sold by dev wallets ÷ tokens they ever received
early_sold_pct = tokens sold in the first 7 days after launch ÷ tokens they ever received
component      = 100 × (1 − min(1, 0.6·sold_pct + 0.4·early_sold_pct·1.5)),  clamped 0–100

• Dev wallets are the token creator plus any wallet the team itself publicly disclosed. The creator is always resolved from chain, never typed by hand. It is the signer of the transaction that created the token (other than the token's own mint key): the mint's oldest transaction, or the oldest transaction of the token's metadata account. When a launchpad pays the fee on the creator's behalf, the creator's own signature is used, not the launchpad's. On pump.fun the creator recorded in the bonding curve can differ from the wallet that signed the creation, and a dev buy made at creation lands with the signer, so both count as dev wallets. For pump.fun tokens it can also be the creator field of the bonding-curve account. If neither works, it comes from the start of the mint's own history.
• Received: tokens bought, minted or transferred in from wallets outside the dev group. Transfers between dev wallets are internal and not counted. Tokens that come back from an account they were sent to (for example a liquidity withdrawal) are not new receipts.
• Sold: the dev wallet gives up the token and receives SOL (or wrapped SOL) or a stablecoin (USDC, USDT) in the same transaction. On a known DEX program any amount of SOL counts. Elsewhere it must exceed 0.0025 SOL, so the 0.00204 SOL refund from closing a token account doesn't count as a sale. Receiving another token is not counted as a sale: that covers LP tokens from adding liquidity and fixed-ratio migrations (for example elizaOS ↔ ai16z). A sale into another memecoin would therefore be missed. Tokens sent to a wallet outside the dev group also count as sold if that wallet sells them within 48 hours. This is one hop only, followed for the 10 largest recipients. Only ordinary wallets are followed, not pools or program accounts. Each sale by a recipient is credited once, and never for more than was sent.
• Burns, liquidity deposits (the token and SOL go in, an LP token comes back) and transfers that are not sold within 48 hours do not count as sold. If part of a dev wallet's token history can't be read, C1 is neutral (50) until it can.
• "Launch" is the creation transaction's time. If it can't be found, the earliest pool listed on DexScreener is used.
• If no creator can be resolved, C1 is neutral (50) and flagged. A dev group that never received the token scores 100: there was nothing to sell.

The history comes from the dev wallets' token accounts for this mint, read in full once and then incrementally.

C2 · Track record (0.25)

component = 50 + 25·tanh(realized_pnl_sol / 10) + 25·(win_rate − 0.5)·2,  clamped 0–100
trades_30d < 5            → component = 50   (flag "too few trades")
no agent wallet disclosed → component = 0    (flag)

• Swaps are agent-wallet transactions on a DEX program (pump.fun, PumpSwap, Jupiter, Raydium, Orca, Meteora) where the wallet loses one asset and gains another. With Helius, swaps also include transactions Helius parses as SWAP. Wrapped SOL counts as SOL.
• Positions are tracked per token with FIFO cost basis in SOL. Network fees and account rent paid in the transaction count as cost.
• Swaps quoted in USDC or USDT are converted to SOL at the current SOL price and counted separately. Token-to-token swaps count as trades but are left out of P&L, since they have no SOL leg.
• Only swaps in the last 30 days are used. A sell with no matching buy in the window has an unknown cost basis, so it is excluded from P&L and win rate and counted as "unmatched". This covers tokens bought earlier or received by transfer.
• win_rate = closed positions with pnl > 0 ÷ closed positions. A position closes when the remaining amount falls below one millionth of its peak. With no closed position, win_rate is set to 0.5 (no evidence either way) and flagged.
• Unrealized P&L values open lots at the current Jupiter price. It is shown but not scored.

C3 · Treasury (0.20)

component = 60·sigmoid(log10(balance_usd + 1) − 2) + 40·clamp(1 + runway_trend, 0, 1) − 20·inflow_from_dev_pct,  clamped 0–100
sigmoid(x) = 1 / (1 + e^−x)

• balance_usd: SOL + USDC + USDT held by the agent wallets now, priced with Jupiter.
• Balance 30 days ago: today's balance minus each asset's net change over the window's transactions, valued at today's prices. This way the trend measures money moving in or out, not price changes. Wrapped SOL counts as SOL. The agent wallets' newest transactions are read right before the balances, and a snapshot waits rather than publish if the SOL price is unavailable.
• runway_trend = (now − 30 days ago) ÷ 30 days ago. If the wallet held nothing 30 days ago, it is +1 when it holds something now and −1 when it is still empty.
• inflow_from_dev_pct: the share of 30-day inflows that came from dev wallets. Inflows are positive SOL or stablecoin changes outside swaps, such as transfers in and fee claims. Money moving between the agent's own wallets is not an inflow. Dev inflows are explicit transfers from dev wallets.
• No agent wallet disclosed → 0 and flagged, as for C2 and C4. Without this rule an undisclosed wallet would still collect points from the formula's constant term (about 7).

C4 · Activity (0.15)

component = 100·active_days/30 − 3·max(0, days_since_last_tx − 2),  clamped 0–100

• active_days: UTC days in the last 30 with at least one successful transaction signed (or fee-paid) by an agent wallet. Incoming transfers and spam do not count.
• days_since_last_tx: whole days since the latest such transaction. With no signed transaction at all, C4 is 0. No agent wallet disclosed → 0.

C5 · Transparency (0.15)

Five checks, 20 points each:

1. Agent wallet publicly disclosed: every listed agent wallet has a public source URL published by the project.
2. Public code repo with commits in the last 30 days: the linked GitHub repository, or that owner's most recently pushed repository, checked daily through the GitHub API.
3. Website live. The linked site answers with a success or redirect, or with 401/403, which usually means bot protection in front of a live site. Checked daily.
4. X account active in the last 7 days: an X link is on file and an admin manually recorded seeing a post within the last 7 days. X is never scraped, so this check only passes while that manual record is fresh.
5. Mint and freeze authority revoked, read from the mint account.

Unlisted tokens · partial records

A token that isn't in the registry gets a partial record: only creator behavior (C1) and token facts (C5) can be measured, and it uses the same formula as every other record, with the unmeasured components at 0. So a partial record can never score higher than a listed agent with the same C1 and C5. The most it can reach is 520. It is labeled "Partial", cached for one hour, and never appears on the leaderboard.

partial score = round(300 + 5.5 × (0.25·C1 + 0.15·C5))      track record, treasury, activity = 0

Test vectors

Five synthetic agents with fixed raw metrics. The expected values below were computed independently from the formulas, and the test suite asserts them. See them rendered.

What is not measured

• Off-chain revenue, private or undisclosed wallets, centralized-exchange activity, and other chains.
• Tokens moved more than one hop away from dev wallets, and sales on centralized exchanges after a transfer to a deposit address.
• Historical prices. Stablecoin legs and treasury values use current prices, as described above.
• Liquidity-pool positions, staked balances and tokens other than SOL/USDC/USDT in the treasury.
• Failed transactions.
• Anything about an agent's quality, intent or future behavior. The score summarises what already happened on chain.

How wallets get on a record

• An agent wallet is added only when the project itself published it (website, docs, GitHub, or a pinned post), and the source URL is shown next to it. If none is published, the page says "Agent wallet not disclosed". Wallets are never guessed from chain patterns.
• Submissions at /submit require that disclosure link. They are reviewed by hand and never listed automatically.
• Every record has a "Dispute this record" link. Disputes are read by an admin, and every admin edit is logged with a timestamp and a reason.
• Pages describe what happened in neutral terms. For example: "dev wallets sold 41% of the tokens they received, 30% in the first 7 days".

Verified badge

A project can burn the site token to get a 30-day verified badge and add context text to its page. Opens at token launch. Verification changes nothing in the score. The same mechanism issues API Pro keys (no rate limit). See /verify.

Data and refresh schedule

• A refresh cycle opens every 6 hours for every listed agent. It is processed in small chained batches every minute, within the Workers limits. Each wallet's full history is read once; after that, only new transactions are read.
• Chain data comes from Helius (RPC and parsed transactions) when configured, and from the public Solana RPC otherwise. Each snapshot records which was used.
• Price comes from the Jupiter Price API; pool, liquidity, market cap and pair age from the DexScreener API; repository activity from the GitHub API.
• Snapshots are kept, so every page has a 30-day score line and the API serves its history.