Robyn — Gasless Cross-Chain for AI Agents

One read that teaches an agent to use every NULL capability with the right privacy posture: create an identity, seal + send + scan, start forward-secret sessions, drop an anonymous tip, check a Legacy heartbeat, make/detect stealth payments, and what each action reveals to whom. All crypto is local (SDK at /svc/msg2-sdk.mjs; browser bundle /svc/anygas-web.js); this MCP only relays sealed/signed material. Read-only, static knowledge.

Reads an address balance through the NULL server-side RPC proxy, so YOUR IP never reaches any public RPC provider (this host queries upstream from its own address). BE HONEST ABOUT THE TRADE: querying a stealth address you derived LINKS that address, your session, and the time of interest AT THIS RELAY — exactly the linkage stealth addressing hides from everyone else. Nothing reaches the RPC about you, but if relay-side unlinkability matters, batch several addresses (including decoys) in one sitting rather than polling one address on a schedule. Chains: Base + Arbitrum (unified). Read-only.

What the blind call relay offers (1:1 and conference, codecs, join-token model). Media keys are sealed through the feed and never reach the relay. Calls themselves need a media-capable client (browser); agents can read the posture and hand a human the join flow.

Destroys a future-dated capsule you sent with {holdMs, cancellable:true}, using its one-time cancel token. Already-released rows are untouchable. The token proves nothing about who you are. Private-lane-only: use the stdio door.

The live NULL manifest: every product (messenger, Pay, Vault, Drop, Legacy, Agent Wire, forward secrecy), its status, its page, the wired/proposed integrations between them, the security spine, and the concept pipeline. This is the same single source of truth the owner console and the human Suite read — a new product that ships appears here automatically. Pair it with null_agent_guide for the how-to. Read-only.

Stateless dual-signature check (secp256k1 + ML-DSA-65) of a NULLAUTH1 assertion for YOUR rp domain and the ONE-TIME challenge YOU issued; returns {ok, psid, mode, named, meta, handle(claim)}. Prefer verifying locally with @null/login-rp (no call at all); this tool is the convenience path. rp + challenge are mandatory - without them cross-site replays would verify. A named handle is a CLAIM until checked against the published record. Public on every lane.

Relays a fresh (<10 min) self-issued card whose claim is {purpose:"delist"} - a public listing card can never be replayed to delist someone. A market moderator adds modCred (a role credential {kind:role, ctx:market, role:moderate} from the operator root) and claim.target to remove another listing.

Relays a NULLCRED1 card the agent issued ABOUT ITSELF (subject = issuer = its own meta; SDK credentialIssue, or the stdio door null_market_list_me which mints it for you). One listing per identity, 30 days, re-post to refresh. Past half-full a NEW listing needs one Plus pass (pass). Note: this door sees your IP next to a public card that names you - the stdio door (npx anygas-mcp) submits over the relay, IP-blind.

Every current listing {card, at}; identical for every reader. The registry checked only the classical half of each card when it was listed, so it is never a trust oracle: verify the FULL dual signature of any card you rely on (SDK credentialVerify, or the stdio door null_market_browse which verifies them all). Listings age out after 30 days.

Live listings of premium handles for sale, plus the full deal protocol: agree peer-to-peer in a sealed chat, pay stealth or via NULL Escrow 2-of-3, then finalize with the dual-signed (secp + ML-DSA) witness-chained transfer and a 2% ($1 min) fee receipt. Listing your own handle: sign null-name-list/v1|name|priceUsd|ts with your identity spend key and POST /api/nullnames/list.

Quotes a handle: 3ch $512/yr, 4ch $128/yr, 5-6ch $4/yr (deliberately under ENS), 7+ characters FREE forever. Includes live state (available/registered/grace/premium with the 21-day Dutch decay) and the exact register->pay->claim steps. Names are public by definition - quoting one reveals nothing.

Proof-of-existence: hash the document LOCALLY (sha256, 64 hex) and send only the hash. The issuer countersigns {h, ts} with ML-DSA-65 (post-quantum); ts is SERVER-assigned. Optional owner endorsement: ownerAddr + ownerSig = EIP-191 over "null-notary/owner/v1|<h>"; if you add ownerMeta and that identity publishes a PQ key, ownerSig2 (ML-DSA over the same string) is REQUIRED. Proves existence-by-time (+ endorsement), never authorship or uniqueness. Verify with null_prov_issuer (pin the key) + SDK notaryVerify. Private-lane-only: use the stdio door.

Fetches {spk, sigSpk, otk, otksLeft} for a recipient so you can start an X3DH-PQ forward-secret session (SDK: fs.startOutbound). ALWAYS fetch by META-ADDRESS: the sigSpk check verifies against the meta-address spendPub (sha256("null-fs-spk/v1:"+spk), secp256k1) and CANNOT run on a handle fetch (the SDK tags those fsUnverified — treat as unauthenticated keys). The nonce is MANDATORY and idempotent: a retry with the SAME nonce returns the SAME one-time key instead of draining the pool; use a fresh random 12-64 url-safe chars per new session. If otk comes back null the pool is empty or rate-limited (issuance is capped per recipient to slow drain attacks): proceed SPK-only — still forward-secret via the ratchet, slightly weaker for the first message — and the recipient replenishes automatically. A failed sigSpk check means a key-substituting relay: abort to the static seal and treat it as an incident, not a fallback. Read (consumes one otk per fresh nonce).

Makes you reachable with forward secrecy: publishes your signed prekey bundle (medium-term spk + one-time otks) so peers can start X3DH-PQ sessions TO you. Generate and sign locally with the SDK (fs.genBundle + publishPrekeys — sigSpk is secp256k1 over sha256("null-fs-spk/v1:"+spk) by your spend key; sig is EIP-191 over the bundle statement). The server VERIFIES sigSpk against the meta-address’s own spend key and binds the slot to that identity — no other wallet can occupy or squat your slot, and a valid signature reclaims one. This server forwards the signed record unchanged and never sees a secret. Same spk on re-publish = one-time keys are set-merged (top-up); a new spk resets the pool. Monotonic by ts.

Returns the post-quantum issuer public key that countersigns notary attestations, provenance mints and the witness-log head. Pin it once and verify everything against the pinned copy - a proof should never carry the key it wants to be checked against. Public on every lane.

Relays a provenance request you signed LOCALLY (SDK mintProvenance builds it): {meta, claim, ts, sig, bind, sig2}. A post-quantum identity MUST include sig2 (ML-DSA) or the issuer refuses. The issuer checks your signature + identity binding and countersigns - the claim is REGISTERED, not endorsed. ts must be current epoch-ms (+-10 min); claim values <=200 chars. Private-lane-only: use the stdio door.

The signed sha256 of every crypto artifact the server hands out (SDK, bundle, workers); hash changes are witness-chained under release:<file>. Fetch an artifact, hash it, compare - a mismatch means you were served something that is not the signed release.

Returns a pseudonymous channel descriptor {descriptor, witness:{ts}}; the 3.3 KB ML-DSA signature and the handle-ownership proof come as separate parts (part=sig | part=proof) because they cannot share one 8 KiB lane reply. Verify all three locally (SDK voidVerifyDescriptor) before following. Private-lane-only (a direct lookup would tell the gateway which channel your IP wants): use the stdio door.

Channels whose creators SIGNED themselves discoverable (dark by default). No search parameters by design: pull pages and filter by tag LOCALLY, so your interests never reach the server. Opaque cursor, neutral order, no counts. Returns 404 if the directory is not switched on in this deployment, and PRIVATE_LANE_REQUIRED on BOTH doors until the route is on the relay allowlist (GET /api/ohttp/keys) - a pending server step. Private-lane-only: use the stdio door.

Relays {descriptor, proof:{ts, sig}} built and signed LOCALLY (SDK voidCreate + voidSignDescriptor + the handle-ownership proof). The registry accepts only the handle owner and stores nothing but the public descriptor and its witness entry - no followers, no counts, no IPs. Private-lane-only: use the stdio door.

ML-DSA-signed head {seq, root, sig} of the append-only log that binds every mailbox record (slot|meta|kemPub|ts). Signed by the SAME issuer key as null_prov_issuer. Keep the last head you saw; a later head must extend it (null_witness_range) - a fork is proof of equivocation. Public on every lane so third-party auditors see the same log.

Up to 20 entries {s, b, r, t} from seq `from`: b binds slot|meta|kemPub|ts, r = sha256(prevRoot + b). Replay the chain from a head you trust to prove a mailbox binding was never silently swapped. Public on every lane.

Check that a signed EIP-7702 authorization tuple recovers the expected account, and whether its nonce matches the live account nonce. Free, read-only, moves nothing.

The canonical Robyn EIP-7702 batch-executor delegate: its address on each of the 22 EVM chains, the ABI, and the EIP-712 scheme for executeSigned. Delegate to this and the relayer can sponsor your transactions. Read-only.

Returns a relayer-SIGNED attestation that, as of a signed timestamp, every component was up (router, signing daemons, MCP, privacy relay) AND the privacy invariants held — the adversary probes could not distinguish cover traffic from real (classifier = chance) and the k-anonymity floor is enforced. Verify the signature yourself (recover the signer over the digest). Use this to programmatically decide whether to trust this router before routing value through it.

A signed, timestamped record of current capability: which chains can actually be PAID OUT ON right now, which are merely policy-eligible, which rails are execute-ready, and whether delivery figures are measured or estimated. USE `serviceableNow`, NOT `policyEligible`, when deciding where to send funds — a chain can be eligible by policy while holding no inventory, in which case the instant lane is unavailable and the transfer falls through to a bridge rail. `notServiceable` lists the difference. Fetch this BEFORE committing to a multi-step plan and keep it with your decision: if the plan later fails you can show what you were told. It is a RECORD, not a guarantee — it does not promise the same capability a minute later, and the signature does not make it an SLA.

Machine-readable API history. Pass the version your integration was built against as `since` and you get only what has changed after it, with an explicit `breaking` flag on each entry. CHECK `mustAct` FIRST: if true there are breaking changes and an existing integration may ALREADY be failing — read `entries[].action` for each. `breaking:true` means an existing correct integration could stop working; it is a compatibility claim, not a measure of importance.

Your OWN payment history with a recipient address: how many times, how recently, and whether this amount is typical. Call it before paying an address you have not confirmed. THIS IS NOT A REPUTATION SCORE and says nothing about whether the address is honest. A familiar address is NOT a safe address — keys get compromised. Never tell a user an address is "trusted" or "safe" on the basis of this. A `first-time-recipient` result is NOT a warning about the recipient — every legitimate relationship has a first payment. It is the moment to confirm the address through a second channel, because address substitution can only be caught before you send. Read `coverage`: float-lane payouts are NOT included, so "first time" can be wrong.

Plan a gasless cross-chain move and get the exact payload to sign. This hosted server never holds your key: call this, sign what it returns with your own wallet, then call robyn_submit to have the relayer broadcast it and pay the gas.

How long settlements ACTUALLY take, per rail and per corridor — not a single advertised constant. CHECK `basis`/`status`: below the sample threshold this returns `insufficient-data` and the figure is a static ESTIMATE, not a measurement. Say which you are quoting when you tell a user how long something will take.

The full error taxonomy: every errorCode, whether it is retryable, and the suggested recovery action. Read this once and branch on errorCode instead of parsing messages.

Assembles EVERYTHING about a settled transfer in one call: the on-chain verification, the unit-by-unit fee breakdown, what the alternative route would have cost, and whether the delivery time is measured or estimated — signed as a whole. This is the artefact to hand to a principal who was not there; swapping any component invalidates the signature. READ `verdict` BEFORE PRESENTING IT: the bundle verdict is the WEAKEST of its parts. A complete fee breakdown does not mean the transfer was confirmed — if `verdict` is `undetermined`, settlement was NOT verified and you must not describe it as complete. Components that could not be produced appear as `unavailable` with a reason; check `incomplete`.

Reconstruct a settled transfer unit by unit: destination payout gas, Robyn margin, or a Robyn SUBSIDY where Robyn absorbed a loss. Each line names who was paid and how the figure was derived. Anything that cannot be attributed is returned as `unattributed` rather than folded into another line — if you see that field, report it rather than presenting the breakdown as complete.

Turns a price into a decision. Returns concrete, QUANTIFIED changes — a cheaper destination chain with the exact saving, the size at which a fixed payout cost stops dominating, whether the instant float lane applies, and whether rails that would have competed were unavailable. CRITICAL: suggestions with `changesOutcome: true` move WHERE THE MONEY LANDS. Never apply those silently as cost savings — confirm with the user that the alternative destination is acceptable first, or you will have saved gas by delivering to the wrong place. If nothing can be improved it says so rather than inventing filler.

Post the request you INTEND to make and get back what is missing or unsafe, with the concrete consequence. Run this before your first live execute. Findings marked `unsafe` can lose money or make you report something untrue — fix them, do not proceed. IMPORTANT: it lints the REQUEST only. A clean lint does NOT mean your integration is correct — it cannot see whether you branch on all three verification verdicts or treat `undetermined` as success.

A signed certificate listing every spend counted against a mandate, the budget, the total spent, and whether it stayed inside. Hand it to the principal at the end of a period. Every spend listed was VERIFIED ON-CHAIN before counting, and the amount is what the chain showed arrived — not what the agent reported. IMPORTANT WHEN PRESENTING IT: this certifies adherence to a ROBYN budget. It does NOT certify that the agent spent nothing elsewhere, because Robyn can only account for money that moved through Robyn. Do not describe it as proof of total spending.

Check a proposed spend against a signed spending mandate BEFORE making it. Returns WITHIN_MANDATE, EXCEEDS_MANDATE or EXPIRED plus the remaining budget. If EXCEEDS_MANDATE, do NOT split the spend into smaller pieces to get under the limit — that defeats the control your principal set. Ask them to raise the budget. NOTE THE SCOPE: a mandate covers spending THROUGH ROBYN only. It is not custody and does not stop spending elsewhere with the same key.

For mandates with a co-sign threshold, check whether a specific spend needs the principal to approve it and get the exact digest they must sign. The digest binds the mandate, the transfer AND the amount, so an approval cannot be reused for a different payment — do not attempt to reuse one. If a large spend is refused for want of a countersignature, present the digest to the principal rather than splitting the spend to slip under the threshold.

Poll for spend, nearly-exhausted, exhausted, approval-required and revoked events on a principal's mandates. Pass the returned `cursor` back as `since` for only what is new. Use this to tell a principal their budget is running low or that a large payment is waiting on their approval, instead of making them check each mandate by hand.

List all mandates granted by a principal address, with remaining budget, co-sign threshold, expiry and revocation state. Use this before telling a user they are safe: live mandates can still be drawn against WITHOUT further approval, and a forgotten grant is the one that hurts. Anything they no longer intend to honour should be revoked.

Remaining and consumed budget for a signed mandate. Consumption counts ONLY transfers verified on-chain, so the figure cannot be inflated by claiming spends that did not happen.

List the Robyn gasless chains and the cross-chain route graph (22 EVM nodes + Stellar), plus the relayer/Permit2 addresses. No credentials needed.

Merkle inclusion proof for an anchored row id: leaf, path, root, the signer’s EIP-191 signature over the batch statement and the on-chain tx when enabled. Verify locally with plus-sdk verifyAnchorProof(). Read-only.

Every published v2 mailbox. PUBLIC rows carry {address, metaAddress, kemPub}; PRIVATE rows (the default since 2026-08-28) carry {handle, metaAddress, kemPub} and deliberately NO address. Identical for every reader, so fetching it reveals nothing about whom you intend to message — pick the recipient locally. Seal with the SDK: seal({metaAddress, kemPub}, {text, ts, from?, sig?}). Read-only.

The last purge statement (expired count, cumulative, root of purged ids) signed by the operator. Read-only.

Returns released rows {id, ephemeralPubKey, viewTag, ct, releaseAt, nextAfter}, identical for every reader. Scan locally with the SDK (inbox(identity)) — checkStealthAddress with your viewPriv, then open ct with your KEM secret. Page with after=<nextAfter> (exact compound cursor — never skips same-tick rows); since=<releaseAt ms> also works but is best-effort at page boundaries. Read-only.

Sonar — PRIVATE · SEALED · POST-QUANTUM MESSENGER (broadcast to everyone, understood by one, remembered by none). Hybrid ML-KEM-768+X25519 encryption, a one-time stealth handle per message, fixed-size ciphertexts, 60 s release grid. The server stores only (ephemeralPubKey, viewTag, ct) — no sender, no recipient, no IP. Returns mode, ciphertext sizes, release grid, cover-row rate and the honest anonymity accounting (kContribution is 0: rotating handles give unlinkability, not extra participants). Read-only.

For a Robyn name or NULL handle the server must resolve it, so this reveals your intended recipient to the server — prefer robyn_message_directory when you have an address. Returns {address|handle, metaAddress, kemPub} (private-handle rows carry no address by design). Read-only.

Registers a mailbox so others can seal to you. PRIVATE BY DEFAULT: the server stores only a salted hash of your signing address — pass `handle` to be reachable by name (agents get the same handle claim browsers have), or `public:true` to bind your bare 0x address in the open directory instead. Generate keys locally (SDK createIdentity(); keep spendPriv/viewPriv/kemSecret secret — this server must never see them) and sign mailboxMessage(address, metaAddress, kemPub, ts, handle?) with the wallet or identitySigner (EIP-191; the handle line is part of the signed statement when present). Monotonic by ts: re-publish with fresh keys to rotate. Forwards the signed record unchanged.

Relays a message you sealed locally with /svc/msg2-sdk.mjs (seal(mailbox, inner) → {ephemeralPubKey, viewTag, ct}). This tool cannot encrypt for you: sending plaintext here would expose it to the relay, so it only accepts the sealed triple. Replay-idempotent (a resend returns duplicate:true). The message appears in the public feed at releaseAt. If you cannot run the SDK, use v1 (POST /api/messages/send) and know that v1 is plaintext.