Register a service
The Service Registry is permissionless. Registering is a signed event you publish to the network — there is no application, no reviewer, and nobody who can refuse you. What follows is what the protocol requires, and what happens after.
How it works, end to end
- 1
Run the service
Stand up whatever you are offering — a Telegram gateway, an FX oracle, a snapshot host, a public API node. The registry advertises services that exist; it does not provision them.
- 2
Establish your identity
Generate the node key pair and have a wallet ready to sign with. The peer ID falls out of the key pair; the public key is published alongside it.
- 3
Sign a registration event
Assemble the fields below, sign them with your wallet, and publish. The event propagates over the gossip protocol — no registrar, no queue, no approval.
- 4
Publish health updates
Providers periodically advertise Online, Maintenance, Degraded or Offline. Clients use it to route around you when you are down — and if you stop publishing entirely, your registration expires on its own and stops appearing in discovery.
- 5
Get selected
Clients query their local registry and choose between providers on region, latency, capabilities and price. Being listed is not being used; you are competing with everyone else offering the same service.
What a registration event contains
- Service ID
- Globally unique, and permanent — changing endpoints or pricing never changes it (§8).
- Service type
- One of the registry's types. A provider may run several services, each with its own ID.
- Provider identity
- The wallet, node identity, peer ID and public key above.
- Network endpoints
- Where clients reach the service. Multiple endpoints are normal — one per region.
- Supported protocol versions
- So a client can tell whether it can talk to you before it tries.
- Geographic region
- Which regions you serve, if you want to say. Self-declared and unverified — nothing in the protocol measures where a service is, and nothing ever will: geolocating an endpoint would answer where your socket terminates, which is a different question from who you serve. Clients see it labelled as declared.
- Capabilities
- What the service actually does — currency pairs for an oracle, channels for a gateway, retention for snapshots.
- Branding
- A name, a sentence, a logo and a website, all optional. The logo is an IPFS CID rather than a URL, so viewers fetch it from their own access node and nobody learns who looked at your listing. Names are not exclusive: the registry will not stop someone else registering yours, so your Service ID is what identifies you.
- Pricing
- If you charge. Optional, and advertised as metadata rather than enforced by the registry.
- Timestamp and signature
- The event is signed and gossiped to the network. There is nothing to submit to anyone.
Identity you need first
- Wallet address
- Signs the registration and every later update. Whoever holds this key controls the service entry.
- Node identity
- The name your node publishes itself under, stable across restarts.
- Peer ID
- Derived from your node's key pair. This is what a client dials, and what proves it reached you rather than someone advertising your hostname.
- Public key
- Published so anyone can verify your signatures without asking you for it.
Service types
- NotificationsNotification Provider
- Price OraclesOracle Provider
- Risk IntelligenceRisk Intelligence Provider
- SnapshotsSnapshot Provider
- Merchant GatewaysMerchant Gateway
- API NodesPublic API Node
Governance may add types over time. A provider may run several services; each gets its own Service ID.
No stake, no permission
The registry itself asks for nothing but a signature. Individual service specifications may require a stake — a risk intelligence provider whose data moves disputes has more to answer for than a snapshot host — but that is set by the service, not by the registry you are registering with.