What is MOTE?

MOTE is a registry for businesses and people who want to be found by AI.

Most of the internet was written for humans. Search engines, blog posts, product pages, social profiles — all of it optimized for eyeballs. AI agents read differently. They skip the pretty parts and look for structured, verifiable facts. If those facts don't exist, the agent guesses or skips you entirely.

MOTE gives your business a permanent on-chain identity and a set of machine-readable files that AI agents can trust. One $10 registration. No subscription.

The idea in one line

A mote is the smallest unit of light. Collectively, motes become illumination. Each registered business is a mote — together, the network illuminates the commercial web for AI.

What you get for $10

• A Decentralized Identity (DID) anchored to the Sui blockchain in under a second. Permanent. Not revokable, even by us.
• An llms.txt file at mote.network/m/yourname that any AI crawler can read.
• Submission to the official MCP Registry, Smithery, PulseMCP, and mcpservers.org.
• A merchant dashboard where you control your profile, see reputation, and complete your presence.

What happens after you register

The moment you pay $10, three things happen — automatically, in under a minute. You don't need to do anything.

What to do next

Complete your profile in the dashboard. The more you fill in — hours, location, what you sell, how to reach you — the more confidently an AI agent can recommend you.

Everything else is automatic.

Your profile page

Every MOTE registration creates a permanent public page at one URL. Humans see one rendering. AI agents see another. Both are reading the same source.

"did": "did:sui:0xabc...d34f",
"name": "Joe's Coffee Shop",
"category": "food_beverage",
"established_year": 2018,
"location": {
  "city": "Mercer Island",
  "state": "WA"
},
"hours": {
  "mon": "07:00-18:00",
  "tue": "07:00-18:00",
  ...
},
"products_count": 47,
"amenities": ["wifi", "wheelchair"],
"payment": ["cash", "card", "apple_pay"],
"reputation_score": 87,
"verified": true

One source. Two renderings. The richer your profile, the smarter the answer.

When a human visits mote.network/m/your-business-name, they see your business profile. When an AI agent fetches the same URL — through .json, llms.txt, or the MCP server — it gets the structured, machine-readable version of the same data.

You update one place. Both views update together.

Three layers of profile

Layer 1 — Your on-chain identity (auto-created at registration)

Your DID, your business name, your category. Permanent. Written to the Sui blockchain in under a second. This is what $10 buys you.

Layer 2 — Your minimum profile (about 3 minutes to fill in)

Hours, location, contact details, a short description of what you do. Enough for an AI agent to surface you when someone asks for "a coffee shop near Mercer Island." This is the bare minimum that gets you found.

Layer 3 — Your complete profile (ongoing, in your dashboard)

Products, SKUs, payment methods, accessibility, amenities, languages, certifications, photos, what makes you different. Every field you add is one more reason an AI agent picks you instead of someone else.

The merchants who win at AI discovery

The merchants who win are the ones who treat the dashboard like Google Business Profile. The bare minimum gets you on the map. The complete profile gets you recommended.

What "richer profile" actually means

When an AI agent answers "what's the best coffee shop in Mercer Island for a Sunday morning meeting with WiFi?" — it can only choose between businesses whose data answers that question. A profile that lists hours, WiFi, accessibility, and product range is competing for that recommendation. A profile with just name and category isn't.

We don't make the decision. Your data does.

Your DID (permanent ID)

Your DID is the proof your business exists — and it lives on a public blockchain, not in MOTE's database.

A Decentralized Identifier — DID — is a permanent, unique address anchored to a public blockchain. The moment you registered, MOTE minted a DIDState object on Sui mainnet in your name. You own it. MOTE cannot delete it, edit it, or transfer it. Even if MOTE disappeared tomorrow, your on-chain record persists forever.

The trust architecture

Two Sui addresses are recorded inside every DIDState: the minter (MOTE's treasury, which paid the gas to create it) and the owner (you). The separation is cryptographic proof that MOTE creates the identity but does not control it. Any AI agent, regulator, auditor, or customer can verify this directly on-chain, without trusting anything MOTE says.

What's actually on-chain

Your DIDState object contains four fields — and nothing else:

What's NOT on-chain: anything personally identifiable. Your email, phone, address, private dashboard data — none of that touches the blockchain. Only the four fields above. We're anchoring identity, not publishing your life.

Verify yours (or anyone's)

Every MOTE profile API response includes an on_chain block:

"on_chain": {
  "network": "mainnet",
  "object_id": "0x63fc530f32f2189936801bf6749c4c7dd6151d333be157222eecd629211df176",
  "explorer": "https://suiscan.xyz/mainnet/object/0x63fc530f...",
  "verified": true
}

The explorer URL is the one-click proof. Open it in a browser, and you're looking at Sui mainnet directly — not at anything MOTE controls. That's the whole point.

Real example: Hoshi Sora was the first merchant ever registered on MOTE. Verify it yourself: suiscan.xyz/mainnet/object/0x63fc530f...

Where you'll find it

Three places:

What MOTE paid for, and what you own

MOTE paid the gas. You own the record.

MOTE covered the ~$0.003 cost to mint your DIDState on Sui mainnet. You didn't need a wallet. You didn't sign anything. You didn't touch a seed phrase. But the record on-chain is in your name, owned by your address — not MOTE's.

You got a permanent on-chain identity without any of the friction crypto usually demands.

What MOTE can and cannot do

What MOTE can do:

• Update the profile data we serve on your behalf (hours, products, etc.)
• Refund your $10 if something goes wrong
• Help you with your account

What MOTE cannot do:

• Edit, delete, or revoke your on-chain DIDState
• Prevent anyone from verifying your identity directly on Sui
• Take your record down if we went offline

What's different from full self-custody (Phase 1)

Today, MOTE still manages the Sui wallet that owns your DIDState — we encrypt the keys and store them so you don't have to deal with a seed phrase. We're working on user-facing self-custody (so you can hold your own keys if you want), but it's not live yet. The on-chain record is yours; full key-management is a Phase 2 addition.

Why this honesty matters

A database row can be modified, deleted, or faked. An on-chain record cannot. Most "verified business" services are the first kind. MOTE is the second. That's the whole product.

Verification & impersonation

Anyone can register a business name. The question is: how does an AI agent — or your customer — know it's actually you?

The verification chain

Three independent signals confirm a MOTE listing is real:

What happens if someone impersonates you

A bad actor could register joes-coffee-shop on MOTE without owning the real Joe's Coffee. They cannot, however:

• Fake the DID. Their listing will have a different DIDState object than yours, with a different on-chain address. AI agents inspecting the chain can see two listings exist for the same business name and know to flag the conflict.
• Forge the on-chain record. Sui mainnet doesn't let anyone rewrite history.
• Inherit your reputation, your verified domain, or your established date.

If it happens to you, here's what to do:

1. Report the impersonation to MOTE through your dashboard or by emailing support@mote.network with both DIDs and your evidence of ownership (matching domain, business registration, etc.)
2. Verify your real listing immediately — link your domain, email, and any other ownership signals.
3. We investigate impersonation reports within 48 hours. Verified impersonations are removed.

The honest limit of what we can do

We can verify ownership signals. We cannot stop someone from typing your business name into a registration form. The system is designed so impersonation gets caught quickly and verified profiles win — but we are not magic, and the first day after an impersonation may show two listings until we resolve it. Verification speed matters. Verify your profile now, even if you're not impersonated yet — it's your insurance policy.

What about defamation, false product listings, or harm?

If someone registers a profile for your business and lists products you don't sell — or worse, products designed to damage your reputation — that's not just impersonation, it's defamation. Our process:

• Defamatory listings are removed within 24 hours of verified report.
• Repeated bad-actor accounts are blocked from re-registering.
• We cooperate with law enforcement when asked.
• Your real verified DID always takes priority in any conflict.

We don't host content. We host identity. The distinction matters: fake or harmful content in a MOTE listing is not protected speech — it's misrepresentation of an identifiable real-world business, and we treat it accordingly.

Your reputation score

Your reputation score is a number from 0 to 100 that reflects how complete and trusted your MOTE presence is.

What it measures today (Phase 1)

Today, your score is calculated entirely from signals MOTE can verify directly. Customer reviews are not yet part of the score. That capability is planned for Phase 2 — until then, the score is a measure of your presence, not your performance.

What it does not measure (today or ever)

We will never include in your score:

• Money paid to MOTE. No boost packages. No premium tiers. No paid placement.
• Affiliate or partner relationships. No ranking lift for being part of any network.
• Social media followers, off-platform reviews, or external endorsements. Score is internal-signals-only.

What we plan to add (Phase 2)

Customer-side signals will be added when the Bazaar ships and we have a verified transaction record. That means:

• Verified completed transactions through the agentic marketplace.
• Verified disputes and resolution outcomes.
• Time-decayed averages so old behavior doesn't dominate new.

When that ships, we'll publish the scoring methodology in full and give merchants a 90-day window to see their adjusted score before it goes live.

Why this matters

Most "trust scores" online are black boxes. We don't think that's defensible. Your score is built from a small number of verifiable inputs that we can show you, in order, and explain. If we can't justify a signal, we don't include it.

Completing your profile

Your $10 registration gives you a working profile. Completing it is what gets you found.

The dashboard walks you through every field. There's no required order — you can update everything in a five-minute session, or fill in a few fields each week. Either way, every field you add is one more reason an AI agent picks you.

The fields that matter most

The merchants who get found most often have these fields completed:

• Hours of operation — by day of the week, including holidays. Agents looking for "open now" can only surface you if you've told them when you're open.
• Location — city, neighborhood, or "online/global." For local searches, location is the single most important field.
• Contact methods — phone, email, contact form, or DM channel. An agent that finds you needs to be able to hand off the customer.
• Products or services — what you actually sell, in plain language. The more specific, the better. "Espresso, drip coffee, pastries, oat milk available" beats "coffee shop".
• Payment methods — cash, card, Apple Pay, crypto, etc. Important for high-intent searches.
• Accessibility & amenities — wheelchair accessible, WiFi, parking, kid-friendly. These are filters AI agents apply to narrow recommendations.
• Languages spoken — surfaces you in non-English queries.

A complete profile is your moat

Most businesses haven't done any of this work. The few that have are the few that get recommended. For now, completion is the differentiator.

You can update anything, any time

Your profile is yours. Edits propagate to all renderings — your public profile, the JSON view, your llms.txt — within seconds. Agents that re-fetch your profile see your changes immediately.

One thing you can't change: your DID

Your DID is locked at registration. If you sell your business, the DID transfers with it (we have a process for that). If you rebrand, your DID stays the same — your reputation travels with you.

The MCP Registry

MOTE ships an official MCP server, live on the Model Context Protocol Registry alongside Microsoft and GitHub.

The MCP server lets any MCP-compatible AI client — Claude Desktop and any other MCP-compatible client — query the MOTE registry for merchant discovery. Three tools, zero auth, zero cost.

Install

The server is published as mote-registry on npm and on the official MCP Registry at network.mote/mote-registry.

npx mote-registry

That's it for Claude Desktop users — the server self-registers the three tools below.

For other MCP clients, add the server to your config:

{
  "mcpServers": {
    "mote-registry": {
      "command": "npx",
      "args": ["mote-registry"]
    }
  }
}

The three tools

Verification

The server's registry entry:

https://registry.modelcontextprotocol.io/servers/network.mote/mote-registry

The npm package:

https://www.npmjs.com/package/mote-registry

The source (public):

https://github.com/mote-network/mote-registry

Authentication

The MCP server is unauthenticated and free to use for read operations. Every call hits the public MOTE API (api.mote.network), same as a curl from a browser. No API keys, no rate-limit gating, no trial tier.

Fair use applies

We reserve the right to rate-limit abusive traffic, but we've never needed to. If you're building a real product on top of MOTE and expect high volume, email support@mote.network — we'll whitelist you.

The MOTE API

The underlying REST API that powers MOTE's MCP server, the public profile pages, and every .json and llms.txt endpoint.

Base URL: https://api.mote.network

No authentication required for read endpoints. Every response is JSON.

Core endpoints

Returns the full public profile for a merchant by slug or UUID. Includes the on_chain block described in Your DID (permanent ID).

GET /v1/merchants/:slug

Semantic search. Same backend as the MCP server's search_merchants tool.

GET /v1/merchants?q=:query&category=:category

Lists all active business categories.

GET /v1/categories

Plain-text sitemap of every registered merchant — one block per merchant with name, endpoint URL, category, location, and description. Built for AI crawlers that prefer human-readable structure over XML.

GET /sitemap.llms.txt

Example response

A call to /v1/merchants/hoshi-sora returns:

{
  "id": "537a5f16-eb32-4431-bb05-eeddfadc5a9e",
  "slug": "hoshi-sora",
  "business_name": "Hoshi Sora",
  "category": "digital_services",
  "did": "did:sui:0x...",
  "on_chain": {
    "network": "mainnet",
    "object_id": "0x63fc530f...",
    "explorer": "https://suiscan.xyz/mainnet/object/0x63fc530f...",
    "verified": true
  },
  "reputation_score": 87,
  "established_year": 2024,
  "location": { "city": "Bellevue", "state": "WA" },
  "products_count": 3,
  "updated_at": "2026-04-18T21:42:00Z"
}

Every field is documented in the response examples below and in the source. If you're building an integration that needs more detail, email support@mote.network — we'll send you whatever schema reference you need.

Write endpoints

Merchants authenticate to the API with a session token issued at login, scoped to their own merchant record. A merchant can only edit their own profile — no cross-merchant access, ever.

PATCH /v1/merchants/:id
Authorization: Bearer <session_token>

We're not publishing write-endpoint details in these docs yet — the surface is still stabilizing. If you're building a client that needs to write on a merchant's behalf (e.g., an integration partner), email support@mote.network and we'll walk you through the current contract.

Error handling

Standard HTTP status codes. Errors return JSON:

{
  "error": "merchant_not_found",
  "message": "No merchant with slug 'does-not-exist'",
  "status": 404
}

Every 5xx response is logged to Sentry with a correlation ID. If you hit a persistent server error, include the x-request-id response header when reporting.

Rate limits

Read endpoints: 300 requests/minute per IP. Write endpoints: 60 requests/minute per authenticated merchant. Limits are designed for legitimate production use — not hard caps. Email us if you need more headroom.

llms.txt standard

llms.txt is an open proposal for making websites readable by AI agents. MOTE implements it fully, and every merchant's MOTE profile is published at a standard, crawlable URL.

What is llms.txt?

A plain-text file at a predictable URL that tells AI crawlers:

• Who the business is
• What they offer
• Where to fetch structured data
• How to contact them

Think of it as robots.txt for agents instead of spiders. It's designed to be fetched, parsed, and acted on by LLMs without needing to render a visual page.

Where MOTE serves it

Every merchant gets an llms.txt at two URLs:

https://mote.network/m/your-slug/llms.txt
https://api.mote.network/v1/merchants/your-slug/llms.txt

Both serve the same content. The first lives on the public-facing domain (which is what search engines and AI crawlers will typically discover via your sitemap). The second is a direct API fetch, useful for programmatic clients.

What's inside

A MOTE-generated llms.txt looks like:

# Joe's Coffee Shop

> A neighborhood cafe in Mercer Island, WA specializing in espresso, drip coffee, and fresh pastries.

- DID: did:sui:0xabc...d34f
- Category: food_beverage
- Established: 2018
- Location: Mercer Island, WA, US
- Hours: Mon-Fri 7:00-18:00, Sat-Sun 8:00-16:00
- Contact: hello@joescoffee.com

## Products

- Espresso drinks
- Drip coffee
- Fresh pastries
- Oat milk available

## Verified on Sui mainnet

https://suiscan.xyz/mainnet/object/0x63fc530f...

## Structured profile

https://api.mote.network/v1/merchants/joes-coffee

The sitemap

MOTE also maintains a global llms.txt sitemap — a single plain-text file listing every registered merchant, formatted for AI crawlers that want to bulk-ingest the registry:

https://mote.network/sitemap.llms.txt

One block per merchant, updated as merchants register or edit their profiles. This is what we ping to Google and IndexNow on every change.

Why not just JSON?

Agents can fetch JSON too (every merchant profile is available at .json). But llms.txt has two practical advantages:

The spec

MOTE tracks the official proposal at llmstxt.org. We implement the proposal cleanly and contribute issues back when edge cases come up.

The Bazaar

The agentic marketplace where AI agents discover MOTE merchants, negotiate terms, and settle payments — all on-chain, all without a human in the loop.

The problem we're solving

Today, when an AI agent finds your MOTE profile, the conversation ends there. An agent can tell a customer about you, even verify you're real and legitimate. But the moment the customer wants to buy, they're handed back to you — and to your website, your POS, your card processor, your payment timeline. That handoff breaks the promise of agentic commerce.

The Bazaar closes the loop.

How a transaction flows

When a customer asks their AI agent to book a service, three things happen:

Why merchants should care

Today, most businesses are invisible to AI agents. Tomorrow, the agents will be placing the orders. If your business isn't where the agents are transacting, you don't see the revenue. The Bazaar is where that revenue will flow.

Registering on MOTE today — as a Phase 1 identity listing — gets you onto the runway before the jets land.

What we're not promising

We don't know exactly when the Bazaar will ship. Smart contract audits, legal review, regulator conversations — these are the gating items, not feature development. We'd rather ship something defensible than something fast. Your $10 registration carries forward regardless — the Bazaar isn't a new SKU, it's the Phase 2 capability of the registry you're already on.

What we've already built

• Sui Move smart contracts for intent, bid, and escrow (deployed on testnet, pending formal third-party audit).
• Database tables for intents, bids, jobs, and disputes (schema complete, on mainnet DB).
• SDK stubs for merchant-side bid automation.

What we're still waiting on

• Formal smart contract audit (scheduled).
• Legal opinion on money-transmitter exposure (in progress).
• First-party agent integration — we need at least one major AI agent platform with a paying-customer flow to make the Bazaar useful at launch.

Live Pricing Intelligence

A private, cryptographically-secured price-discovery layer that lets AI agents compare real-time prices across MOTE merchants — without exposing what any single merchant charges to competitors.

The problem we're solving

Today, if an agent wants to compare coffee prices across ten Mercer Island cafés, it has to scrape ten different websites, parse ten different menu formats, and hope nothing's stale. For agents making real-time decisions on behalf of real customers, that's untenable. For merchants, being publicly price-indexed means every competitor sees your prices as fast as agents do — a race-to-the-bottom problem.

Live Pricing Intelligence solves both, using privacy-preserving computation.

What privacy-preserving computation does (plain English)

Privacy-preserving computation. It lets a computer answer questions about encrypted data without decrypting it.

Specifically:

The question HOOT can answer

"Who has the lowest price for a 12oz drip coffee, delivered to 98040 on Sunday at 9am?"

An agent can ask this question. The system can answer it — returning the winning merchant — without anyone (including MOTE) ever seeing the individual prices. Merchants submit encrypted price matrices. The oracle returns cryptographically-signed answers.

Why this matters

The honest state

This is the furthest-out part of the roadmap. The cryptographic primitives we'd need at the performance level real-time lookups require are still maturing — we're watching the research closely. When we ship HOOT, it will be because we can do it well. Until then, your registration today earns you the right to participate when the capability goes live.

Why we're telling you about it now

Most roadmaps hide the ambitious stuff. We're showing it because:

1. It shapes what we build today. Every architectural decision in Phase 1 and Phase 2 is being made with Live Pricing Intelligence in view.
2. You might have opinions. Merchants with specific pricing-privacy concerns — competitive categories, regulated industries, legally sensitive pricing structures — we want to hear from you. Email support@mote.network.
3. We'd rather tell the truth than overclaim. The ambition is real. The timeline is honest.

x402 Payments

Native support for the HTTP 402 "Payment Required" status code — the web's forgotten payment primitive, now relevant again in the era of agentic commerce.

What x402 is (plain English)

When you visit a webpage and it's paywalled, the server technically returns HTTP status 402 Payment Required. Browsers don't know what to do with it — no major browser actually implements a 402 flow — so the web mostly ignores it.

Agents don't have that problem.

An AI agent fetching a URL can be handed a 402 response that says "pay X to get this content," and then actually pay it — programmatically, at machine speed, from the merchant's or user's wallet. x402 turns any URL into a potential paywall, any API endpoint into a metered resource, any merchant profile into a bookable offer.

What MOTE will do with it

What we've already built

Foundations are in. Every MOTE merchant's profile payload includes a signed x402 manifest today — the JSON descriptor that says "this merchant can be paid at this address, using this protocol, for these kinds of offers." Agents querying our API already receive it. It's the plumbing waiting for a tenant.

What's needed before this actually works

Two things, neither of which is in MOTE's hands:

1. Agent-side x402 client support. AI agents need to know how to handle a 402 response and execute payment. This is coming fast — several of the major agent platforms are announcing x402 support over the next 6–12 months.
2. Merchant-side custody architecture. Before any merchant receives payments through MOTE, we'll implement the non-custodial handover architecture described elsewhere. That's a deliberate pacing choice.

The honest frame

x402 is the most "merchant infrastructure is already ready, ecosystem infrastructure is catching up" of our Phase 2 plans. We can flip this on the day the agent ecosystem is ready — and when that day comes, every merchant registered on MOTE will be payment-capable without doing anything. Your registration today is the entry ticket to that day.