Overview
What Kyro does
Kyro is a wallet credential layer for Arc and stablecoin applications. A user connects an EVM wallet, signs a verification message, claims a public .kyro profile and receives an Identity Score based on real indexed activity and verified transaction evidence.
The product is built for checks that happen before payments, lending, escrow, protected deals, merchant flows and higher-value stablecoin interactions.
Launch phase
Kyro runs on wallet signatures, Supabase persistence, Arc transaction verification, external chain indexers, cached score snapshots and verified trust graph records. Some external providers can be rate limited or plan restricted. The UI reports those cases as Limited coverage so the product stays understandable while Arc-native data and cached intelligence remain visible.
Core primitives
The building blocks
Wallet identity
Connect an injected EVM wallet, sign an ownership message and claim a public .kyro username. The signature proves control before anything is written.
Identity Score
One reputation score from 0 to 100. It combines indexed wallet history, Arc ecosystem activity, verified attestations and risk signals into a single number.
Global wallet profile
Multi-chain context: wallet age, transaction count, chain coverage, counterparties and contract interactions across supported networks.
Arc network footprint
Arc-specific activity read live from Arc RPC and indexing, backed by verified Arc transaction attestations when explorer coverage is limited.
Verified attestations
Transaction-backed trust evidence. An attestation only exists after the submitted Arc transaction is verified against both wallets.
Trust graph
Verified wallet-to-wallet edges with reciprocal relationships, network maturity, anomaly hints and tightly capped trust propagation.
Score model
One score, explainable components
Kyro exposes one primary score. Supporting components explain why the score moved but they are not separate competing scores.
Score model v2_2026_07 combines global wallet maturity, Arc-specific activity, verified transaction attestations, capped trust propagation and evidence-based risk controls. Component points sum to the score after any risk penalty, then clamp from 0 to 100.
Claiming a username grants no points. A fresh wallet with no indexed activity, no Arc footprint, no verified attestations and no trust graph evidence starts at the real component total: 0. The score rises only when Kyro can verify meaningful wallet behavior.
Global wallet age
20 pts
Maturity from the earliest real indexed transaction across supported chains.
Chain coverage
5 pts
Supporting context from active chains with successfully indexed activity.
Indexed transactions
15 pts
Maturity context from real indexed transactions. Raw volume alone cannot dominate the score.
Counterparty diversity
15 pts
Unique global counterparties plus higher-signal Arc and verified transaction relationships.
Arc activity
25 pts
Arc transactions, Arc counterparties, active days, Arc age and the current balance signal.
Verified attestations
15 pts
Only transaction-backed attestations with unique tx hashes and registered counterparties.
Trust propagation
5 pts
A tightly capped signal from verified trust edges. Network influence cannot outweigh wallet behavior.
Risk penalty
up to -10 pts
Applied only from supported anomaly evidence or excessive repeated-pair concentration.
Score stability
The same persisted evidence always produces the same score. A refresh commits atomically only after indexing finishes. Temporary provider failures preserve the last verified evidence instead of treating unavailable chains as zero, so repeating refresh cannot walk a score up or down.
Verified attestations
Transaction-backed trust
Verified attestations are not social claims. A user submits an Arc transaction hash, a registered counterparty and an interaction type. The backend verifies the transaction on chain before any reputation or trust graph effect is applied, and the counterparty can accept or decline.
Requires a real Arc transaction hash
Transaction must exist and succeed on Arc
Connected wallet and selected counterparty must both participate
Duplicate transaction hashes cannot be reused
Self-attestations and unsupported interaction types are rejected
Only verified transaction-backed attestations can create trust edges
Only submit attestations for legitimate economic interactions. Circular trust farming, fake activity or abusive verification behavior can reduce trust confidence and trigger anomaly records.
Trust graph
Verified relationships, not social follows
Trust edges are created only from accepted, verified transaction-backed attestations. Usernames, manual profile data and unverified activity do not create graph relationships.
The graph tracks trusted peers, strongest relationships, reciprocal edges, total trust weight, network maturity, anomaly hints and a capped propagated trust contribution. The dashboard renders it as a live instrument where distance from the center reflects trust weight.
Verified edges only
Every edge maps to a real Arc transaction between two registered identities.
Reciprocal confidence
Two-way relationships carry more signal than one-way attestations.
Capped propagation
Trust flowing through the network is limited to 5 points of the score.
Reliability model
Fast reads, careful refreshes
Score reads are cached-first. GET /api/score/:wallet returns the best available cached profile quickly, including cache status, refresh status, last indexed time, explanations, chain coverage and trust summary.
Full indexing happens through POST /api/score/:wallet/refresh. The pipeline uses lifecycle states so incomplete or failed provider checks never overwrite the last good cached score.
Provider returned usable activity and the chain contributes real indexed data.
Provider responded successfully but found no transactions for the wallet.
External provider access is unavailable, rate limited, paywalled or temporarily restricted.
Required API key or provider configuration is missing.
The wallet has not been checked yet or a refresh is still running.
Developer API
Reputation data for builders
Any Arc app can query Kyro before payments, lending, escrow, protected deals, merchant flows or high-value stablecoin interactions. Full request and response documentation lives on the Developer API page.
GET
/api/score/:wallet
Cached-first score with breakdown, explanations, chain coverage and trust summary.
POST
/api/score/:wallet/refresh
Runs a full wallet intelligence refresh through the background-safe pipeline.
GET
/api/profile/:username
Public profile: wallet, score, attestations, reputation events and trust graph context.
GET
/api/profile/by-wallet/:wallet
Resolves a wallet address to its claimed identity and cached profile.
GET
/api/users
Claimed public identities for the directory.
POST
/api/attestations/request
Creates a transaction-backed attestation after Arc transaction verification.
POST
/api/attestations/respond
Lets the counterparty accept or decline a pending attestation.
GET
/api/trust/:wallet
Trust edges, snapshots, anomalies, reciprocal peers and network metrics.
GET
/api/onchain/:wallet
Raw indexed on-chain intelligence for the wallet across supported chains.
Sample response
GET /api/score/:wallet
{
"walletAddress": "0x...",
"username": "example.kyro",
"arcIdentityScore": 72,
"scoreModelVersion": "identity_score_v1",
"riskLevel": "Reliable",
"cacheStatus": "cached",
"refreshStatus": "committed",
"breakdown": {
"globalWalletAge": 16,
"crossChainActivity": 4,
"transactionActivity": 11,
"arcActivity": 18,
"counterpartyDiversity": 9,
"verifiedAttestations": 10,
"propagatedTrust": 4,
"riskPenalty": 0
},
"trustGraph": {
"trustedPeerCount": 2,
"networkHealth": "emerging",
"trustConfidence": 64
}
}FAQ
Common questions
Is Kyro a manual reputation form?
No. Profiles are wallet-owned. Reputation comes from indexed wallet activity, verified transaction-backed attestations and trust graph context. Claiming a username adds zero points.
Why can some chains show Limited?
Some external indexers have rate limits, plan restrictions or temporary outages. Limited means provider coverage is constrained, not that the wallet is risky.
Can someone farm score with fake attestations?
Attestations only count after the Arc transaction is verified on chain. The backend checks participants, duplicate use and relationship rules before any trust is created.
Does the score update instantly?
Score reads are cached-first for fast pages. Full indexing runs through a refresh pipeline and the dashboard keeps the last good score visible while a refresh completes.
Is the system final?
No. Kyro is in an active launch phase. Score explanations, provider coverage, trust safeguards and developer responses keep improving as usage grows.
Get started
Run the launch flow
Connect a wallet, sign the ownership message, claim a username and refresh wallet intelligence. Then inspect your public profile and try a transaction-backed attestation once you have a real Arc transaction with another registered identity.