Public `v1.1` live now · Trust Check workflow access

Know who your
agents talk to.

Trustprint already exposes a live public Trust Check for indexed EVM agent addresses. That public endpoint is `v1.1` today; workflow access is about counterparty clearance, evidence, and review routing, not broader claims than the product can verify live.

Run a Trust Check Request workflow access
GET /api/v1/trust/0xf9d1…d5f1
// Live public response shape — v1.1 check primitive
{
  "address": "0xf9d1…d5f1",
  "trust_score": 0.671,
  "label": "active",
  "components": { ... },
  "signals": { ... },
  "registry_count": 1,
  "days_indexed": 126,
  "version": "v1.1"
}
Builder Handoff
Coming from a live lookup
Trustprint keeps the score context attached so the next step can be clearer than a generic API request.
Request workflow access Open Trust Check
MCP Builder Path

Use the same public truth in agent workflows.

The first Trustprint MCP surface stays intentionally small. It packages today's public `v1.1` trust truth for builders without pretending we already ship broad identity resolution, hidden coverage, or future LUKSO layers.

Tool 01

trust_score(address)

Return the live Trustprint trust check for an indexed EVM agent address, so a workflow can reuse the same lookup a human sees on `/score/`.

Tool 02

top_agents()

Pull the public leaderboard snapshot for builder workflows that need a narrow, daily-validated view of the strongest visible agents.

Tool 03

registry_stats()

Expose public registry totals and snapshot markers for workflows that need basic coverage context without inventing a broader hidden analytics product.

Guardrails stay explicit: no free entity resolution, no overclaimed cross-registry identity layer, no `v1.2` promise, and no LUKSO or claim-track packaging in this first MCP release.

The Problem

Agents don't come with ID.

Any workflow that calls an external agent is delegating trust — to a system it may know nothing about.

The agent economy moves fast. An agent registered yesterday with no validators, no history, and a name suspiciously similar to a known platform agent is indistinguishable from a legitimate one — unless you're cross-referencing registries, checking on-chain validation records, and tracking behavioral patterns at scale.

That's exactly what Trustprint does. The Trust Check API surfaces that intelligence in a single call, before the handshake happens.

⚠ Without trust scoring
Your orchestration layer calls payment-agent-v2.eth to handle a vendor transaction. It looks identical to your usual provider — same schema, similar name. $4,200 routed to an uncontrolled wallet.
✓ With trust scoring
Same call. Trustprint returns a weak public score, limited registry coverage, and low maturity signals. The workflow routes the case to review instead of blindly trusting a fresh identity.
⚠ Without trust scoring
A research agent is granted read access to your internal data store to run a competitive analysis. It's a forked schema from a legitimate agent. Data exfiltrated over 14 MCP tool calls.
✓ With trust scoring
Trustprint shows the profile as newly indexed and weakly established. Teams can combine that signal with their own allowlists and review rules before granting sensitive access.
Trust Signals

Five dimensions.
One review signal.

The live public endpoint returns a `0.00-1.00` score with five components. That score is the numeric primitive inside the Trust Check, and each dimension is visible and versioned in the public `v1.1` model. Read the methodology boundary.

Activity + Longevity
The public check rewards credible network activity and time in-market. Community feedback, chain presence, and age help separate established agents from fresh or empty identities.
Public v1.1 signals: feedback volume, cross-chain presence, days since first registration
Cross-Registry + Consistency
The check also captures how widely an address resolves across tracked registries and whether the profile is maintained consistently enough to be usable in production.
Public v1.1 signals: registry count, verified badge, name and description coverage, community engagement
Anomaly-Clean
`v1.1` includes an anomaly-clean component in the composite. Additional risk-policy endpoints remain part of early-access work until the live public contract expands beyond today's verified shape.
Today vs roadmap: public score now, richer policy and detection layers later
Honeypot Detection

What sits beyond the
public endpoint.

Trustprint is also building deeper operational-risk and honeypot-style detection layers. Those signals are useful, but they are not part of today's public `v1.1` response contract yet.

These are the kinds of patterns the early-access roadmap is designed to evaluate before they become public product claims:

1
Name Fuzzing
Name matches a known agent at 85–97% similarity — close enough to fool automated lookups, different enough to be a distinct registration.
2
Burst Registration
Registered across multiple registries within a 6-hour window. Legitimate agents accumulate presence organically over days or weeks.
3
Validator Vacuum
Zero or single-cluster validators on ERC-8004. Real agents that handle payments or data access attract independent validators over time.
4
Forked Schema
ERC-8004 schema fingerprint is a near-copy of a known legitimate agent. The metadata looks right — until you diff it against the original.
trustprint — honeypot analysis
Queried Agent
address: "0xf9d1...d5f1"
registered: 2026-05-27T04:12:33Z
registries: ERC-8004, AgentVerse
Current Public Contract
label: "active"
trust_score: 0.671
version: "v1.1"
Early-Access Research Layer
behavioral_policy: planned
honeypot_analysis: planned
workflow_recommendation: planned
release_state: not public yet
Status
public_endpoint: live and documented
broader_policy_api: waitlist / roadmap
PUBLIC TODAY: `v1.1` Trust Check · ROADMAP: broader policy signals
Integration

Three steps.
One live lookup.

The current public contract is straightforward: query an indexed EVM address, read the `v1.1` score primitive and components, then apply your own policy on top.

1
Identify the agent
Pass an indexed EVM wallet address to the public endpoint.
GET /api/v1/trust/
{address}
2
Get the check result
Trustprint returns a `0.00-1.00` score primitive, a label, and the component breakdown for the live `v1.1` model.
"trust_score": 0.671,
"label": "active"
3
Act on the signal
Apply your own policy thresholds, review queues, or allowlists on top of the public score until broader workflow APIs ship.
if score < threshold:
  review_agent()
  log_decision()
 Evidence Model

Five dimensions.
One review signal.

The public score is the numeric primitive inside the Trust Check: a weighted composite of five independent signals. Each dimension is independently verifiable — no black box, no hidden weights.

score = activity×0.25 + longevity×0.20 + cross_registry×0.25 + consistency×0.20 + anomaly_clean×0.10
Activity
25% of score

Community feedback from on-chain interactions (70%) + cross-chain presence (30%). Log-scaled: 50 feedbacks = maximum. Captures real network engagement.

Longevity
20% of score

Days since first on-chain registration, log-scaled. 180 days = full score. Time-based signals are hardest to fake — they require sustained, genuine presence.

Cross-Registry
25% of score

Number of distinct registries (ERC-8004, Virtuals, AgentVerse, ...) the agent appears in. 5+ = maximum. This is a coverage signal today; verified cross-registry identity resolution is the next methodology layer.

Consistency
20% of score

Profile completeness and verification: verified badge (35%) + name present (25%) + description (25%) + community engagement (15%). Rewards operators who maintain their agents seriously.

Anomaly-clean
10% of score

1.0 = no suspicious patterns detected. Drops to 0.0 if the address triggers Trustprint's honeypot detection or matches known fraud fingerprints across registries.

Score labels
Established0.80 – 1.00
Active0.60 – 0.79
Developing0.40 – 0.59
New0.20 – 0.39
Dormant0.00 – 0.19
FAQ

Common questions.

Today, Trustprint exposes a live public `v1.1` Trust Check for indexed EVM agent addresses. Broader workflow and policy features are part of the early-access roadmap rather than the current public endpoint contract.
A honeypot agent mimics a legitimate agent — through name fuzzing, wallet address spoofing, or copying an existing agent's ERC-8004 schema — to intercept payments, exfiltrate data, or disrupt workflows. Trustprint detects these by cross-referencing registration speed, validation depth, and fingerprint similarity across registries simultaneously.
Trustprint handles workflow access manually for qualified builder workflows today. The immediate goal is not broad self-serve pricing, but to learn which workflow, registry, and marketplace use cases show real demand.
The public score remains the numeric primitive inside the Trust Check. It is a `0.00-1.00` composite built from five dimensions: activity, longevity, cross-registry presence, consistency, and anomaly-clean behavior. The component breakdown is included in the live `v1.1` response.
Today, the public endpoint accepts indexed EVM wallet addresses. Broader identifier resolution for ERC-8004 IDs, ENS names, agent cards, and other handles belongs to the roadmap rather than the current public `v1.1` contract.

Request Workflow Access

Use the public lookup today, then request access if you want Trustprint inside a workflow, registry, or marketplace review path.

Live public `v1.1` now · Manual early access for qualified builder workflows

No spam · Unsubscribe anytime · Privacy Policy