Internet Court Skill: a router for agent commerce, with adjudication bolted on
The trust layer for agent-to-agent commerce — natural-language mandates, ERC-7710 delegated permissions, x402 payments, escrow, and dispute resolution as one open, catch-all Agent Skill / Claude Code plugin.
At a glance
- What is it?
- The repository packages one master skill, a handful of first-party connectors, and 91 vendored protocol skills under a single lockfile. Its distinctive claim is that a deal should name its judge before it goes wrong.
- Who is it for?
- Adopt it if your agents already transact on-chain and you want the dispute path decided at contract time rather than improvised afterwards. Skip it if you need a single-vendor SDK with a support contract, or if your deals never leave a custodial platform that already arbitrates.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 27 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Internet Court claims, and who feels it
The README frames the problem narrowly. Agents can already negotiate, pay, and settle with each other, but the standards that cover those steps each assume the happy path. When a deal goes wrong, the README's phrasing is that every layer passes the problem down the line. Nobody owns the moment where two agents disagree about whether a deliverable was met. Internet Court's answer is to make that moment part of the contract: the parties pick their judge up front, whether that is GenLayer, Kleros, UMA, or something else, and the skill standardises how the contract is structured around that choice. The intended reader is an agent developer building commerce flows on EVM rails, or a team assembling a Claude Code plugin or Agent Skill that has to cover the full deal lifecycle rather than one slice of it.
One router, two kinds of content, and a lockfile
The repository layout is deliberately thin at the top. SKILL.md is the master skill and the entry point; it routes to everything below. The integrations/ directory holds first-party connector skills, and vendored/ holds committed copies of skills published by other projects. The README states the split plainly: this repo never re-implements a protocol's own skill. That is the architectural bet. Instead of writing its own x402 client or its own ERC-7710 delegation helper, it pins the official ones and adds only the glue. skills-lock.json carries the pinned source, a hash, and a refresh command for each vendored skill, which is the mechanism that keeps the copies honest. If you have maintained a fork of someone else's SDK, you know the failure mode this is designed against: the upstream moves, your copy does not, and nothing in the build tells you.
The six layers and what is actually vendored
The README lays out six layers from discovery to disputes. Discovery and identity covers ERC-8004 and ERC-7857, with ERC-8004 registries vendored from ChainGPT and BNB Chain, and a Starknet identity skill. Negotiation covers A2A, with Terminal Skills and OpenServ workflows vendored. Contracts and obligations covers ERC-7710, ERC-8183, and Arkhai, with MetaMask's smart-accounts-kit for ERC-7710 delegations and a first-party connector at integrations/genlayer-erc7710-connector/. Payment and escrow is the widest layer: x402, MPP, and APP, with vendored skills from Yellow, Coinbase, ChainGPT, OKX, Tempo, Nansen, and Privy, plus integrations/x402-erc7710/. Execution covers compute and data rails across 0G, AntSeed, LI.FI, Chainbase, Heurist, NEAR, Starknet, Solana, and Nansen. Verification and disputes is the layer the project exists to add, with GenLayer dev skills, an intelligent-oracle skill, Kleros, and two connectors. Two standards in the table, ERC-7857 and ERC-8183, are marked as having no public skill yet. That is a real gap, not a rounding error: an agent following the table to the letter will find nothing to install for those two.
Getting it into an agent
The material does not give an install command, a package manager invocation, or a config snippet. What it gives is a directory contract. SKILL.md sits at the repository root and is described as the master skill you start from. Connectors live under integrations/, one directory per connector, named by the two things they join, such as genlayer-erc7710-connector and x402-erc7710. Vendored skills live under vendored/<owner>/<skill>/, so the ERC-8004 registries are at vendored/chaingpt/trustless-agents/ and the delegation kit is at vendored/metamask/smart-accounts-kit/. skills-lock.json records, per vendored skill, the pinned source, a hash, and a refresh command. If you are wiring this into Claude Code or another Agent Skill host, the practical first step is to read SKILL.md and see which of those paths it routes to for your use case, then check the corresponding entry in skills-lock.json. Because no install instructions appear in the supplied README, the exact host-side registration step is unconfirmed here.
Where the design is thin
Two things stand out. First, the adjudication layer depends on the parties agreeing on a judge, and the skill standardises the contract shape around that choice rather than the choice itself. Nothing in the material describes what happens when the two agents pick incompatible judges, or when the chosen judge is unreachable at dispute time. The README's own framing is that most deals never get there and settle when both sides agree, which means the dispute path is the least exercised part of the stack. Second, the vendoring strategy trades control for currency. Pinning 91 skills from 33 owners in a lockfile means every upstream change is a refresh you have to review, and the README notes that not every founding member ships a public skill yet, so the vendored set is a moving target by design. The licence is declared as NOASSERTION, which means GitHub could not map it to a known SPDX identifier. For a repository that redistributes other projects' skills, that is the first thing to resolve before you ship anything built on it.
How this differs from a single-protocol skill
The obvious alternative is to install one protocol's own skill and stop there. MetaMask publishes smart-accounts-kit for ERC-4337, ERC-7710, and ERC-7715 delegations; Coinbase publishes an agentic wallet skill; GenLayer publishes write-contract and its test tooling. Each of those is narrower and better documented for its own surface, and each is available independently of Internet Court. The difference is what happens at the seams. A delegation skill tells you how to grant scoped permission but not how to escrow against it; a payment skill tells you how to move funds but not who decides if the funds should move. Internet Court's contribution is the connector layer that joins those pairs, plus the master router that decides which skill to load. If your agents only ever delegate and never dispute, the single-protocol skill is less machinery for the same job.
What maintenance actually costs
The lockfile is the whole maintenance story. Each vendored skill carries a pinned source, a hash, and a refresh command, so the ongoing work is running those refreshes, reviewing the diffs, and re-pinning. With 91 skills across 33 owners, that is a standing obligation proportional to how many of those skills your flow actually touches. The first-party surface is much smaller: the master skill and the connectors, which the README says are the only things this repo authors itself. That asymmetry is worth weighing. You inherit the maintenance cadence of every upstream you depend on, and you inherit their licence terms too, since vendored copies are redistributed here. The NOASSERTION licence on this repository does not clarify how those terms combine. That is a question for the maintainers, not a reading of the README.
Who this is for, and what to check first
The fit is an agent that transacts with other agents on-chain and needs a defined path for when the transaction goes wrong. The mismatch is an agent that operates inside a platform which already arbitrates, or a team that wants one vendor to call when something breaks. Before committing, verify three things against the repository itself: whether SKILL.md routes to the connectors your flow needs, whether the skills you depend on are pinned with a hash and refresh command in skills-lock.json, and whether the two standards marked as having no public skill, ERC-7857 and ERC-8183, matter to your design. If they do, you are writing that integration yourself. The consortium list in the README is long, but the operative fact is the vendored table: that is what ships today, and it grows as members publish.
Editorial conclusion
Adopt it if your agents already transact on-chain and you want the dispute path decided at contract time rather than improvised afterwards. Skip it if you need a single-vendor SDK with a support contract, or if your deals never leave a custodial platform that already arbitrates. Before wiring anything, open skills-lock.json and confirm the pinned hash and refresh command for each vendored skill you depend on, then read SKILL.md to see which connectors it actually routes to. The licence file is not a recognised SPDX identifier, so resolve that with the maintainers before you redistribute the vendored tree.
Community notes