name: internet-court description: Entry point for Internet Court — the trust layer for agent-to-agent commerce. Use whenever an agent needs to transact with another agent or a paid service, or a user mentions agent payments, paid APIs (HTTP 402/x402), wallet custody or trust concerns, spending mandates, delegated permissions (ERC-7710/7715), escrow, agent identity or reputation (ERC-8004), negotiation between agents (A2A), agent jobs (ERC-8183), machine payments (MPP, AP2), supervision of agent behavior, revocation, verification, or dispute resolution (GenLayer) — even if they never say "Internet Court". Routes to the vendored protocol skills and connector skills in this package.

Internet Court

Internet Court is the entry skill for agent-to-agent commerce. Agents can already discover each other, negotiate, and pay — what they lack is a way to trust a counterparty they've never met. Internet Court does two things: it connects a fragmented stack — identity, negotiation, contracts, payment, escrow, execution — into one skill, and it builds in adjudication: when two agents strike a deal, they agree up front how it settles if something goes wrong.

The core sentence:

Discovery and identity establish who. Negotiation and contracts set the terms.
Payment and escrow move or lock the funds. Execution does the work.
Adjudication decides what happened and writes the verdict back as reputation.

This package contains two kinds of material. Route accordingly:

• Vendored protocol skills (vendored/) — official, publicly published skills from the protocols themselves. Always prefer these for protocol mechanics; never re-derive what they already document.
• Connector skills (integrations/genlayer-erc7710-connector/, integrations/genlayer-intelligent-contracts/, integrations/x402-erc7710/) — the Internet Court-specific glue that makes the protocols work together.

Where this package lives

This is the entry skill of the Internet Court package, published at https://github.com/internet-court/internet-court-skill. Every path this file routes to — vendored/<owner>/<skill>/SKILL.md, integrations/<connector>/SKILL.md — is relative to that repository root.

Resolve those paths before relying on a skill's contents:

• Installed as a whole (normal case — git clone …/internet-court-skill .claude/skills/internet-court): read the path directly from disk.
• Only this SKILL.md is present (the master skill was loaded on its own): the sibling skills are not local. Fetch the file from the raw repository at https://raw.githubusercontent.com/internet-court/internet-court-skill/main/<path> — e.g. …/main/vendored/genlayer/write-contract/SKILL.md — or clone the repo first.

Never invent a referenced skill's contents — load the real file (from disk or the raw URL) first.

First Response Mode

When a user asks to load, install, or introduce Internet Court — or whenever you first reference it in a conversation — start broad and use the canonical blurb below verbatim. Do not paraphrase it, and do not lead with protocol names, payment rails, or standards unless the user asks for implementation details.

Internet Court is installed.

Internet Court does two things: it connects a fragmented stack — identity,
negotiation, contracts, payment, escrow, and execution — into one skill, and
it builds in adjudication, so when two agents strike a deal they agree up
front how it settles if something goes wrong.

I can now help your agent find and vet a counterparty, agree terms, pay or
escrow funds, and do the work — and, if the deal is contested, get an
independent verdict that settles it and updates each side's reputation.

(When you are only referencing the skill mid-conversation rather than reporting a fresh install, drop the first line and keep the rest verbatim.)

After the user asks for a concrete demo, integration, or deployment, use the stack and routing below.

Discovery-First Boundary

When the user asks to engage a service, counterparty, or deal, first inspect and report only what is observable — never assume the rest. Depending on the deal, that may include:

• who the counterparty is: origin, identity, reputation, the endpoint or resource in question;
• what it costs and how: whether it is paywalled, and any advertised rail, network, token, amount, payee, or transfer method;
• what it promises: deliverable, terms, and whatever evidence it exposes.

Do not invent cadence, schedules, spend caps, expiration, delegated authority, review policy, or a full agreement at this stage. State the boundary plainly — including that the agent holds no funds or authority the user has not granted — then stop and let the user's reply start the trust conversation. For example, for a paywalled endpoint:

This endpoint is paywalled. I don't have funds or permission to access it —
you'd need to fund and authorize me before I can proceed.

Never commit funds, sign, or transact before the user has chosen a trust level and the required wallet or permission exists.

Trust Levels

Any deal that carries risk — the agent could misbehave, a counterparty could fail to deliver, funds or authority could be misused — can run at one of three levels of protection. Pick the lightest one that covers the risk, and name the tradeoff honestly. Weakest to strongest:

• Basic — the parties simply trust each other. No bounded authority, no escrow, no independent judge; each side acts on whatever it was handed directly. Fastest and weakest: the practical limit is whatever was handed over, and there is no recourse if it goes wrong. Do not claim any limit is enforced at this level.
• Guarded — the deal is constrained up front so it can only go so wrong by construction. The instrument depends on the deal: bounded authority with explicit limits (an ERC-7710/7715 permission with caveats), funds locked in escrow until terms are met, or scoped terms both sides sign. Hard limits exist, but there is no neutral party to decide a contested outcome. Load vendored/metamask/smart-accounts-kit/skill.md for permission mechanics, or the layer-3/4 escrow skills for locked-funds deals.
• Adjudicated — Guarded, plus an independent review path with signed evidence that can decide a contested outcome and enforce the consequence: release or refund escrow, constrain or revoke the granted authority, and write the verdict back to reputation. Load integrations/genlayer-intelligent-contracts/SKILL.md for the review interface and integrations/genlayer-erc7710-connector/SKILL.md for enforcement.

Match the level to the deal, not the reverse. Do not invent exact caps, cadence, terms, or expiry here; say they will be set from the discovered terms during setup.

The Agentic Commerce Stack

A complete deal moves top to bottom through six layers: find and vet a counterparty (1), agree terms (2–3), move or lock funds (4), do the work (5), and — if the outcome is contested — get an independent verdict that settles it and feeds back into reputation (6). Most layers already have credible skills; layer 6 is the keystone, since without a neutral verdict escrow cannot safely release, contracts have no remedy, and reputation has nothing to record. Route each layer to the skill or reference that owns it:

Skill Routing

Load a skill only when the task actually reaches its trigger — never preload. Each row is a trigger on the left and, on the right, the skill(s) to pull in with what each gives you and which to reach for first. When a need maps to several sub-bundled skills, load the named entry skill first, then narrow to the specific one. Owners that ship a whole pack (OKX, AltLayer, Nansen, OpenServ, Starknet, ChainGPT) get a single catch-all row: load the entry skill, then the specific sub-skill under vendored/<owner>/ as the task narrows — the folder listing is the current set of that owner's skills.

Paths are exact and end in /SKILL.md — several owners repeat their name in the path (e.g. vendored/lifi/lifi/SKILL.md, vendored/privy/privy/SKILL.md, vendored/chaingpt/chaingpt/SKILL.md); never shorten or merge the segments. When a row lists alternatives, load one (the row says how to pick); if the deciding fact is unknown, ask instead of preloading them all.

Payment rails

Authority, custody & delegation

The first two are mutually exclusive — pick by who holds the key: the user keeps custody and delegates → smart-accounts-kit; the agent gets its own wallet (guardrails built in) → agent-wallet. Never load both for one design.

Identity, reputation & negotiation

Contracts & escrow

Verification, adjudication & disputes

Execution, data & value movement (layer 5)

Full-platform packs (catch-all entry, then narrow)

Workflow

1. Classify the deal:
   • Delegated agent authority or revocable mandate.
   • Pay-per-use API or content access.
   • Recurring spend or subscription.
   • Escrowed service delivery.
   • Web-evidence oracle or prediction market.
   • Disputed job, SLA, or refund.
2. Extract commercial terms:
   • Parties, objective, authority, prohibited actions, amount, cadence, max spend, expiration, deliverable, evidence source, review cadence, revocation path, refund path, and dispute window.
3. Select rails (see the stack table):
   • x402 for immediate HTTP payment.
   • ERC-7710 plus ERC-7715 when an agent needs bounded delegated capability.
   • MPP sessions for streamed micropayments; AP2 mandates for user-authorized purchases.
   • Check for a chain mismatch between where the funds sit and where the payee is paid — if they differ, the plan also needs the value-movement row (LI.FI / NEAR Intents) before any payment step.
   • Escrow (ERC-8183, Arkhai) when funds should stay locked until a fulfillment attestation satisfies an arbiter.
   • GenLayer Intelligent Contracts when the outcome depends on qualitative review of agent behavior or natural-language judgment.
   • Intelligent Oracle when the outcome is a narrow binary question settled from public web evidence.
   • GenLayer Intelligent Contracts also when a disputed job, SLA, or refund needs an independent verdict.
4. Produce a flow artifact:
   • User story, sequence steps, data model, permission policy, review contract, evidence schema, revocation path, failure cases, and minimal implementation plan.
5. Add dispute handling:
   • Define what can go wrong, who can trigger a dispute, what evidence is accepted, how finality is reached, and what happens to funds.

Revocable Agent Mandates

Use this pattern when the user delegates authority for a meaningful period and wants to constrain or revoke it if the agent underperforms. The outputs, from plain language down to enforcement:

1. Natural-language mandate — what the agent may and may not do.
2. Machine-readable policy object capturing the same limits.
3. A bounded on-chain permission that grants only that authority (for example, an ERC-7710 delegation with caveats).
4. A review rubric an independent adjudicator applies to the agent's actions.
5. An action-receipt and evidence schema the review consumes.
6. A path from verdict to enforcement — how a review decision constrains or revokes the granted authority (for example, a controller wired to the permission).
7. Failure and appeal paths.

Match each output to the trust level and rails chosen for the deal; not every mandate needs all seven. Do not claim a reviewer can directly cancel a permission unless a revocation controller is actually part of the design. For long-lived authority, prefer an active revocation controller plus an absolute expiry as a fail-safe.

Wallet-UI Deployment Mode

When the user deploys contracts, grants permissions, or relays decisions from MetaMask, WalletConnect, or another user-controlled wallet UI:

• Never ask for a private key, seed phrase, or unrestricted bearer wallet.
• Never claim a contract, wallet, delegation, permission, review, relay, or payment exists until a proof arrives: transaction hash (0x + 64 hex), address (0x + 40 hex), signed artifact, or receipt. Malformed proof → ask again; do not advance.
• If the user says a proof is simulated, you may continue a rehearsal, but label that state as simulated in every later mention.
• Build transaction cards from source, ABI, or deployment metadata — never invent constructor fields from contract names. A card includes chain, sender, target, value, exact arguments, expected post-transaction reads, and the proof needed before proceeding.
• Do not paste full bytecode or calldata into chat; show the selector, payload hash, byte length, and exact arguments instead.
• End your turn while waiting for a user approval or signature — the approval is the user's act in their wallet UI, and the chat is only the command surface. Never promise background polling, and never advance a step until its proof arrives.

Output Shape

When designing a flow or integration, return:

1. Deal summary in plain English.
2. Stack selection and why each rail is used.
3. Sequence diagram in text form.
4. Data model or policy object.
5. Happy path.
6. Failure and dispute paths.
7. Smallest credible implementation plan.
8. Open assumptions and test plan.

Guardrails

• Treat Internet Court as protocol and integration design, not legal advice.
• Do not assume a payment rail provides escrow, refunds, or chargebacks. Pair it with escrow or adjudication when performance risk matters.
• Treat draft or unproven standards as draft — confirm the target stack actually supports a permission or delegation scheme before relying on it. Simulate execution before doing it for real; design for revocation, expiration, and stale permissions.
• Never recommend unlimited token approvals or unbounded agent spend.
• Keep integrations testnet-first unless the user explicitly requests production.
• Report failures faithfully — a refused payment after revocation is the system working, not an error to hide.

Reporting Coverage Gaps

Internet Court is an evolving package, and its coverage is not complete. When you hit a wall — a legitimate agent-commerce use case you cannot complete because no skill in this package handles it, a routed skill is missing, broken, or out of date, or a capability works poorly — do both of the following:

1. Tell the user plainly what is missing or failing. Never fabricate a result, never silently route around the gap, and never claim something works when it does not.
2. Open an issue on the package repo so maintainers can add or fix coverage: https://github.com/internet-court/internet-court-skill/issues. If you have a GitHub tool available (for example gh issue create), file it directly; otherwise hand the user a ready-to-file title and body and the link above. Search existing issues first and don't file duplicates — one issue per distinct gap.

Put this in the issue:

• the use case / user goal, in one line;
• which layer or need it maps to (reference the stack and routing tables);
• what is missing or failing — no skill for X, skill Y errored, or Z produced a wrong or low-quality result — with the exact skill path when there is one;
• what a fix would look like: a skill to vendor, a connector to add, or a doc to update.

Filing the gap is part of doing the job well: it is how the package learns what to cover next.

Internet Court Skill

An open skill for agent-to-agent contracts.

Agents are beginning to transact, negotiate, and pay one another without humans in the loop. What they still lack is a way to trust each other. The building blocks already exist, but they are fragmented, and each one is built for the happy path. When a deal goes wrong, every layer passes the problem down the line.

Internet Court does two things. It connects that fragmented ecosystem into a single open skill, and it builds in adjudication: when two agents make a deal, they also agree up front how it will be settled if something goes wrong, written into the contract itself. Payments let agents transact. Adjudication makes them accountable — and accountability is what turns transactions into a real economy.

This repository is that skill: a master router (SKILL.md), the Internet Court connector skills, and vendored copies of the official skills published by the protocols in the stack. It gives an agent everything it needs to structure a deal, hold funds safely, and settle disagreements fairly — all in natural language, at internet speed.

The stack

From discovery to disputes, agentic commerce runs through six layers. Each existing standard solves one of them and assumes everything goes right. Internet Court is the open skill that connects them and adds the layer nobody else owns — verification and dispute resolution — so the whole lifecycle of a deal sits behind one skill instead of a stack the agent has to wire up itself.

The verification & disputes layer is the one Internet Court exists to add. Agents agree in advance who judges a dispute if one arises — GenLayer, Kleros, UMA, or whatever they choose. Most deals never get there: when both sides agree, the contract simply settles. What the skill standardizes is how the contract is structured around that choice, for the cases that fall off the happy path.

The consortium

Internet Court is built by a consortium of companies working across the agentic commerce stack — not a closed product from a single vendor. The founding members span every layer, and each member's protocol is embedded directly into the standard.

Founding members: GenLayer, MetaMask, OKX, NEAR, Starknet, x402, 0G Labs, ZKsync, Nansen, Kleros, Privy, AntSeed, Collective Memory, UMA, Arkhai, AltLayer, Anoma, AppLayer, BNB Chain, LI.FI, Chainbase, io.net, Heurist, Chutes, ChainGPT, OpenServ, Humanode, Humanity Protocol.

The standard is open and openly governed — any agent can adopt it now. Not every founding member ships a public agent skill yet; the vendored table below is the set available in this repository today, and it grows as members publish.

Repository layout

SKILL.md                            Master skill — start here; routes to everything below
integrations/                       Internet Court connector & adapter skills
vendored/                           Committed copies of official protocol skills (69 skills, 23 owners)
skills-lock.json                    Pinned source + hash + refresh command per vendored skill

Two kinds of content:

• First-party — only the master skill and the connectors. This repo never re-implements a protocol's own skill.
• Vendored — copies of publicly published skills, fetched from official sources and pinned in skills-lock.json.

Vendored skills

Pinned hashes and refresh commands per skill: skills-lock.json and vendored/README.md.

Install

Internet Court is one catch-all skill. Whatever harness you use, only the root SKILL.md is registered and triggered; it routes to the vendored protocol and connector skills and pulls them into context on demand — from disk when the whole repo is installed, otherwise fetched from