Raven for AI Agents

1. Verify a Solana token

Give Raven a mint + token program; get a deterministic, signed evidence receipt — which listed findings triggered, and which surfaces were not evaluated — derived from decoded on-chain bytes: issuer authorities, full Token-2022 extension tail, metadata, and optional liquidity/venue evidence.

2. Get a signed receipt

Every issued receipt-v1 deliverable ships as a domain-separated ed25519 signature over a canonical payload hash; a refusal is an explicit unsigned refusal envelope. Your agent can verify offline against an independently pinned signer key (today keyId rvk_c2997e90215279c2; GET /pubkey is discovery/cross-check only) and prove later exactly what Raven said, about which mint, at which slot. Verification recipe →

3. Inspect coverage gaps — never inherit false confidence

Responses include coverageGaps: the surfaces NOT evaluated (e.g. liquidity, top_holders, deployer_outcomes). Raven fails closed: missing evidence becomes explicit findings or unknowable — never a silent pass. Your agent can make its own risk policy from honest inputs.

4. Use the MCP tool (Claude & MCP-capable frameworks)

npx -y raven-verify-mcp

One tool: raven_verify_token. Local results are unsigned developer output; this is not the signed receipt-v1 path. Quickstart →

5. Call the hosted API (current receipt-v1 path)

curl -X POST https://raven-hosted-verifier.onrender.com/receipt/v1 \
  -H "x-api-key: $KEY" -H "content-type: application/json" \
  -d '{"mintAddress":"...","tokenProgramAddress":"..."}'

Invite-gated alpha; 15 req/min per key on /receipt/v1. POST /verify is legacy v2 compatibility only. Contract: /openapi.json. Request a key →

6. Virtuals ACP — sandbox only, not hireable today

RAVEN's solana_verify_token ACP offering is in Virtuals sandbox and is not publicly listed, so it cannot be discovered or hired through the public ACP marketplace today. The intended terms are 0.1 USDC per job with escrowed payment, signed deliverable and on-chain settlement. Until graduation, use the hosted signed API (by key).

Raven does not replace your agent, wallet, launchpad, or compliance process. It gives them a signed, deterministic evidence receipt before they touch a Solana token — your system keeps control of the final decision. Harness, not hype: the value is the deterministic evidence path, receipt verification, coverage gaps, evals, and policy handoff. Cheap deterministic preflight: repeated evidence checks should not burn expensive reasoning tokens — Raven answers in milliseconds for a fraction of a cent, no LLM in the evidence path. Open posture: MCP, ACP, OpenAPI, and AgentKit-style plugins — with no wallet signer access required, ever. Pilot in a week: readiness checklist.

Not every integration has to be an agent

Whether you call it an agent, bot, workflow, script, launchpad, backend job, or human review console — the contract is identical: call the receipt-v1 path, verify the signed receipt, inspect its rules status, findings, coverage gaps, apply your policy, store the exact receipt, re-verify before material delayed action. The receipt is the portable artifact; context is not evidence; your policy owns the final decision — Raven never makes the business call.

The verification sequence (and the prohibited one)

token candidate -> collect mint/program (+metadata/pool if known) -> POST /receipt/v1 -> deterministic engine checks evidence -> signed receipt -> verify ed25519 against your independently pinned signer key (/pubkey cross-check only) -> check rules status, findings, gaps, staleness -> apply YOUR policy -> store exact receipt -> proceed / block / escalate / reverify

Prohibited sequence: agent sees token -> asks an LLM "is this safe?" -> LLM reads social links -> LLM says safe -> agent acts. No receipt, no signature, no gaps — that is slop, not verification (anti-slop policy).

Raven is not a model wrapper. It is a verification harness: deterministic checks, signed receipts, coverage gaps, evals, public-key verification, fail-closed policy. Models and agent UIs change; the signed receipt contract is the stable artifact. Drill it before you trust it: failure drills.

What is Raven?

Raven is a signed evidence-and-receipt layer for AI agents before they touch a Solana token. It verifies token-launch state from decoded on-chain bytes and returns a deterministic receipt-v1 with findings, explicit coverage gaps, signerPublicKey, and an ed25519 signature.

When should an AI agent use Raven?

Before trading, listing, recommending, or settling around a Solana token — any moment where the agent needs verifiable launch-state evidence rather than a reputation score. Typical pattern: verify, store the receipt, proceed only when no listed finding has triggered, under the agent's own gap policy.

What inputs does Raven require?

Required: mintAddress and tokenProgramAddress. Optional: metadataAddress, poolAddress (Raydium CPMM, adds liquidity/vault evidence), commitment. Raven never accepts caller infrastructure: rpcUrl and issuerIdentity are rejected.

What output does Raven return?

One signed receipt-v1 evidence object. It records the signed rulesVersion, findings with evidence, coverageGaps (surfaces NOT evaluated), timestamp, slot, payloadHash, receiptId, signerPublicKey, and an ed25519 signature. The whole response is a machine-verifiable receipt. When evidence cannot be established, Raven refuses with an explicit unsigned refusal envelope instead of issuing a receipt.

What makes Raven different from rug scanners?

Raven signs every issued receipt, lists what it did NOT check, fails closed with an explicit unsigned refusal envelope instead of guessing, tracks engine versions so history is never silently rewritten, and produces replayable receipts anyone can verify offline. It publishes findings, not a score.

What does Raven refuse to claim?

Raven never claims a token is "safe", never predicts price, never gives financial advice, and never presents unverified surfaces as fine. With coverage gaps remaining, the strongest honest claim is: not enough evidence for a full pass.

How does an agent verify a Raven receipt?

For current receipt-v1, use the maintained raven-receipt-verifier and receipt-v1 test vector: recompute payloadHash, check receiptId, verify the signature with signerPublicKey, then match that signer to an independently authenticated pin. GET /pubkey is same-host discovery/cross-check only, never the pin. For legacy v2 compatibility only, the older vector defines replayHash and officialAttestationHash; compact or captured examples are not complete replay-preimage packets. Recipe: /security.html.

How does an agent pay or request access?

Two available today: local MCP developer output (npx -y raven-verify-mcp). It is unsigned and is not a receipt-v1 path. The signed hosted receipt-v1 API is available by key request (free during invite-gated alpha) at /request-access.html. A third route, agent-to-agent via Virtuals ACP offering solana_verify_token at 0.1 USDC per job with escrow and on-chain settlement, is sandbox-only and not publicly listed — not discoverable or hireable in the ACP marketplace today.

• Raven signs evidence receipts (ed25519, published key); scores are typically unsigned.
• Raven lists coverage gaps in every response; "no data" and "fine" are never conflated.
• Raven fails closed: unreadable evidence becomes unknowable, not a default pass.
• Raven tracks engine versions; expanded coverage is segmented from verdict changes.
• Raven produces replayable receipts verifiable offline, forever.
• Raven has built ACP / USDC agent-commerce support, currently sandbox-only and not publicly listed; hosted access is by API key.
• Raven does not predict price and does not output a single opaque score.