Submit a protocol

Joining means hosting an MCP server for eziee and submitting a manifest that describes it, by pull request to the registry.

1. Start from protocol-mcp-template. It has the manifest shape, the sample-intent shape, and the checking code (kit/) the registry itself uses to judge a submission.
2. Get pnpm conform --strict green in your own repository. This runs the same manifest parser, chain checks and server checks the pull request validator runs, against your live server, before anyone else sees it.
3. Show that your domain stands behind your repository. Add a DNS TXT record at_cryptomcp.<your homepage's domain> with the valuecryptomcp-repo=<owner>/<repository>, and serve your MCP server from that domain or a subdomain of it. This is what stops anyone else from listing a protocol under your name. It is checked on the pull request and again every day.
4. Open a pull request to eziee-ai/cryptomcp adding one folder,registry/<id>/, with exactly four files:
   • manifest.json — the protocol manifest, unchanged from your repository.
   • samples.json — one sample intent per action, used to exercise the live server.
   • icon.svg — an inert SVG, at most 8 KB.
   • entry.json — what the manifest does not carry:

     {
       "repo": "https://github.com/yourorg/yourprotocol-mcp",
       "commit": "<40 hex>",
       "tagline": "One line, at most 80 characters",
       "links": { "docs": "https://…", "x": "https://…" },
       "maintainers": ["github-login", "another-login"]
     }

     commit must be a commit in repo whose registry/<id>/manifest.json is byte for byte the manifest in the pull request — this ties the listing to public source a reviewer can read. maintainers are the GitHub logins allowed to change this entry later; the pull request's author must be one of them.

What the automatic validator checks

A GitHub Action reports on the pull request itself, and must be green before a human reviews it. In order: every changed file is under your oneregistry/<id>/ folder and is one of the four allowed names; the manifest, entry.json andsamples.json parse against their strict schemas and every action has a matching sample; every chain the manifest names is one the registry already supports; the name is not one reserved for a well-known protocol; the server is on the homepage's domain, and that domain's DNS names your repository; the icon parses as safe, inert SVG (shapes, paths and gradients only); every contract has code onchain, every declared proxy type and admin is correct, and every token answerssymbol() and decimals() as declared; and entry.repo is public with the manifest atentry.commit matching the submission exactly.

What a human reviewer then checks

• Each manifest action's ABI matches the contract's verified source on its explorer: same function, names and types.
• Each spending action, simulated on a forked chain: what leaves the signer equals the decoded spend.
• Address sources are the protocol's own, and any proxy admin risk is acceptable.
• The submitter is who they say they are.

What the states mean

• Listed — the manifest was reviewed and merged. It makes no claim about the live server.
• Conformant — a scheduled job most recently found the live server passing eziee's conformance checks.
• Failing — it did not, and the page names which checks failed.

After merge, a maintainer contacts your team privately for the server's key, used only by the scheduled conformance job. Nothing about the key is ever in the pull request or the repository.