01/Overview
What Kyro is
Kyro is a pre-transaction counterparty decision layer powered by wallet intelligence and reputation evidence. The decision endpoints are the product surface. Wallet intelligence and the reputation graph are the evidence layer underneath them.
Kyro is not AML or sanctions screening and it does not provide legal, regulatory or compliance determinations. Verdicts, scores and receipts are advisory signals for your own decision process. When evidence is missing, Kyro reports a conservative baseline and tells you what was missing instead of guessing.
| Property | Behavior |
|---|---|
| One envelope | { ok, version, data } on success, { ok, version, error } on failure. On every operation. |
| Anonymous by default | Nine public operations work without a key at 20 units per minute per IP. A key raises the rate budget and unlocks the one keyed operation, the interaction-graph refresh. |
| Advisory, non-custodial | Kyro reads public chain data and returns a verdict. It never holds keys or funds and never moves anything. Live on Arc mainnet. |
| Conservative on missing evidence | Unknown wallets get a baseline verdict. Batch rows report no_score instead of a guessed verdict. |
Everything on this page is a summary. The canonical reference for authentication, rate limits, response schemas, reason codes and integration patterns lives at docs.thekyro.co.
02/Decisions
decision_v0.4.1
Three possible verdicts
allow
No caution or block reasons remain.
caution
Soft risk or missing evidence. Proceed with limits or review.
block
Reserved for strong negative evidence: suspicious trust graph, high trust anomaly or high risk penalty.
Missing evidence alone never produces a block. Verdict thresholds are tuned per use case: payment, marketplace, escrow and lending. The full model behavior is documented in the Decision API guide.
03/Quickstart
First call in one minute
No account, no API key and no wallet connection. Call the decision endpoint with any wallet address:
curl "https://www.thekyro.co/api/v1/decision/0x1234567890abcdef1234567890abcdef12345678?useCase=payment"The response is a JSON envelope with the verdict, a recommended USDC limit, reason codes and the evidence behind them. Screen a list the same way, wallets and usernames mixed:
curl -X POST https://www.thekyro.co/api/v1/decision/batch \
-H "Content-Type: application/json" \
-d '{ "inputs": ["0x1234567890abcdef1234567890abcdef12345678", "alice.kyro"], "useCase": "payment" }'Prefer typed calls? The TypeScript SDK is on npm as @kyrodev/sdk (MIT, zero runtime dependencies), with source, examples and CI in the kyro-devkit repository:
import { Kyro } from "@kyrodev/sdk";
const kyro = new Kyro(); // no key: anonymous budget
const decision = await kyro.decisions.check("0x1234567890abcdef1234567890abcdef12345678", { useCase: "payment" });
console.log(decision.decision, decision.recommendedLimit?.amountUsdc ?? null);The step-by-step walkthrough, including unknown wallets, receipts and batch screening, is the quickstart guide.
04/Reference
v1 · frozen contract
Nine public operations plus one keyed refresh
All paths are relative to https://www.thekyro.co. Every operation answers the same versioned JSON envelope. The nine public operations work anonymously; the interaction-graph refresh needs an API key.
| Method | Path | Purpose | Reference |
|---|---|---|---|
| GET | /api/v1/decision/:wallet | Allow / caution / block verdict with a recommended USDC limit, reason codes and evidence. | Docs |
| POST | /api/v1/decision/batch | Screen many counterparties in one call. Rows fail individually, never the whole batch. | Docs |
| GET | /api/v1/score/:wallet | Committed reputation score for a wallet with component breakdown and freshness. | Docs |
| GET | /api/v1/trust/:wallet | Verified trust graph for a wallet: transaction-backed relationship edges and graph metrics. | Docs |
| GET | /api/v1/interaction-graph/:wallet | Observed onchain counterparties from saved snapshots, separate from verified trust and score. | Docs |
| GET | /api/v1/profile/:username | Public summary of a registered Kyro identity by username. | Docs |
| POST | /api/v1/decision-receipts | Mint an immutable, shareable receipt of a decision. | Docs |
| GET | /api/v1/decision-receipts/:id | Fetch a receipt exactly as minted. Receipts never change after creation. | Docs |
| POST | /api/v1/intake/:wallet | Start indexing a wallet Kyro has not seen yet. No signature from the owner is needed. | Docs |
| POST | /api/v1/interaction-graph/:wallet/refreshKey required | Re-index the observed counterparty graph on demand. The one operation that needs an API key. | Docs |
Field-level request and response schemas for every operation are generated from the OpenAPI contract in the API reference, so they cannot drift from live behavior.
05/Access
Beta
Keys and limits
You do not need a key to build. The anonymous budget is 20 units per minute per IP address, 10 unique rows per batch and 25 new wallet scans per day. Most reads cost 1 unit; a batch of N unique rows costs N. Over the limit answers 429 with Retry-After.
API keys raise that budget to a plan and unlock the interaction-graph refresh. During the beta keys are granted by review: send your project, expected volume and use case and the Kyro team replies with next steps. Approved accounts manage their keys per organization in the Kyro Console, where every key shares the organization's plan budget. The Developer plan is free during the beta; Plus and Pro are activated by the Kyro team on request.
Kyro never asks for private keys or seed phrases. Keys are server-side secrets: a key shipped to a browser is handed to every visitor. Verdicts, scores and receipts are advisory signals for your own decision process, not a compliance determination.
End of document · Decision API · v1
kyro-openapi.yaml