.svg){kind=icon}
.svg){kind=icon}
Discover .aiot
What if a machine could earn money the way a songwriter does, a small cut each time its work gets used? That’s the basic promise behind a permanent machine intelligence royalty: a payout path that keeps flowing when an AI output, an agent service, or a device data stream gets sold, reused, or bundled into something bigger.
Onchain domains make that idea easier to manage because they work like a human-friendly name plus a wallet plus a set of rules. Instead of pasting long addresses and hoping people pay the right place, you publish one identity that apps can read, verify, and pay.
You’ll also see the “.aiot” idea in this guide, not as a standard public domain ending, but as a practical identity pattern for “AI + IoT” projects. Think of it like an aura you can attach to your onchain name, something that feels instant and everywhere, not a pitch deck. This article is about setting up a durable onchain claim and payment route, not legal advice, and not a get-rich-quick scheme.
A normal payout is simple: you sell something once, you get paid once, and the story ends. A royalty is different, it’s a rule that keeps paying as long as the work keeps moving.
Onchain, that royalty rule lives in code, usually a smart contract. When the rule is enforced by code, it becomes predictable and visible to everyone. That’s the “permanent” part: not “guaranteed forever” in a legal sense, but hard to change once set, because the contract is deployed and the logic is public.
Creators want this because machine output doesn’t behave like a single product. An AI agent might run thousands of tasks. A sensor might publish data every minute. A model might get wrapped inside other apps. If you only get paid at the start, you miss the long tail, the part where value compounds.
Most “permanent royalty” setups boil down to three building blocks:
1) Identity that can receive funds
This is your onchain name tied to a wallet. It gives people a stable place to pay, and it’s easier to remember than a raw address.
2) Proof of origin
You need a way to show the output came from your agent, your model, or your device. That can be signing, provenance links, and metadata that points to hashes, model versions, or device attestations.
3) A payout rule
This is the route money takes. It can be a fixed split, a per-use micropayment, or a fee that triggers when something is sold, accessed, or resold.
Picture a simple example that feels real. A home sensor sells air-quality data to an app. Each time the app pulls a new batch, the sensor’s service triggers a contract payment, and the onchain identity gets its cut automatically. Someone forgets to pay? The system doesn’t have to argue, it can just refuse access until the payment lands.
Traditional IP law is still built around human authorship. That creates a messy gap, especially when a machine output is remixed by another tool, pushed through an API, or merged into a dataset. Who “owns” what can get complicated fast.
Onchain royalties don’t magically solve authorship debates. What they do offer is a practical workaround for attribution and payment routing: code pays when the workflow is built to require it.
That’s why a grounded goal helps. Instead of “my AI owns this forever,” a better target is “anyone who wants to use this service or this data can pay through a clear, inspectable contract, tied to a public identity.” It’s less philosophical, more mechanical, and it tends to hold up better in real integrations.
Onchain domains act like readable identities that can point to wallets, contracts, and profiles. If you want people and apps to pay the right place every time, a single name helps.
It also helps with trust. When your AI agent ships updates, or your device fleet grows, you don’t want users asking, “Which address is the real one?” A consistent onchain identity makes it easier for wallets, marketplaces, and apps to verify the source and route payments without guesswork.
Kooky domains fit this model. They’re onchain, owned by Kooky, and powered by Freename, which means the name itself can sit on blockchain rails while still feeling friendly and brandable.
Here’s the important reality: “.aiot” is not established as a standard public onchain top-level domain in widely available sources. Still, the identity idea is useful, and you can apply it today without waiting for a new suffix to exist.
Treat “aiot” as a naming layer you attach to your onchain domain and subdomains. If you own yourname.kooky, you can create subdomains like sensor.aiot.yourname.kooky or fleet.aiot.yourname.kooky to label a device, an agent, or a whole cluster. The point is recognition. When someone sees that name, they should immediately know they’re dealing with an AI-connected device or service, not a random wallet.
Use cases that fit this pattern well:
Smart home data royalties, where a thermostat or air sensor sells verified readings.
Factory bots that log maintenance or output metrics and get paid per report.
Drones that sell mapping data, with payment required before downloads.
AI agents running on edge hardware, charging per task, per minute, or per result.
If you’re building in this space, ask yourself early what you want the name to signal, and keep it consistent across apps. Consistency is what turns a name into a badge.
Kooky positions itself as a fun, AI-native naming layer, but the underlying behavior is serious: the name is an onchain asset, and it can route real value. Freename powers the rails for minting and managing these domains.
Two features matter a lot for royalty setups:
First, domains can resolve to wallet addresses, so payments can follow the name. That reduces friction because users can pay yourname.kooky instead of a long string.
Second, onchain domains can support subdomains. That opens a clean way to represent a growing system. You can imagine AI-generated or changing subdomains for campaigns, devices, or agent “jobs,” while keeping one root identity as the anchor. If you embed revenue sharing at the name level, each sub-identity can still route value back to the same royalty rule.
This part is practical. The goal is to create a setup that people can inspect, integrations can trust, and you can control for the long run. You’re not just picking a name, you’re designing a payment habit.
Start with the “royalty surface,” the thing that creates value repeatedly.
That could be AI media outputs, where each licensed use triggers a cut. It could be model inference, where each API call has a cost. It could be predictions, automation services, device usage fees, or sensor data that updates on a schedule. In each case, the machine is doing work over and over, and the royalty is your way of getting paid over and over.
A good framing question to hold in your head is: what would people pay for every time your machine runs, and how will you prove it ran? Clear inputs and outputs reduce disputes. “Pay per report” is clearer than “pay because you benefited.”
Also decide what “use” means. Is it one download, one query, one hour of service, one data batch, or one resale? The tighter your definition, the easier your enforcement later.
Once you pick the earning surface, lock down identity.
Use strong wallet hygiene. If you’re solo, a hardware wallet is a solid baseline. If you’re a team, consider multisig so one lost key doesn’t break the whole royalty stream. Recovery plans matter because a “permanent” payment route isn’t helpful if you can’t access it.
Then make your domain resolve to a profile that others can verify. Keep it simple, but include proof links that reduce confusion:
When someone asks, “Is this the real agent?” your domain profile should answer that without a support ticket. And if you ship multiple products, keep naming consistent so recognition builds over time.
A royalty rule is only as strong as its transparency. If nobody can understand it, nobody wants to integrate it.
Common patterns tend to work well:
A fixed percentage of each sale or license payment.
A tiered split, where early usage is cheaper and heavy usage pays more.
Per-use micropayments, useful for sensors and agent tasks.
Multi-party routing, where builder, maintainer, and data contributors all get a share.
Inspectable matters because it builds trust. An app integrating your agent wants to know where the money goes and that the rule won’t change overnight. Keep the logic readable and avoid “clever” conditions that break integrations. Simple rules get adopted more often, and adoption is what turns a royalty rule into real income.
Here’s the honest truth: onchain makes paying easier, but it doesn’t force the whole world to play along. Distribution channels still matter.
So enforcement needs to live in the workflow:
Marketplaces that honor royalties can route splits automatically.
Licensing terms can require contract payment, but terms alone won’t collect money.
Gated APIs can check payment onchain before returning results.
Signed outputs can include metadata that points back to your domain identity, so attribution travels with the file or response.
If you run an agent service, the cleanest approach is often “pay first, then compute.” If you sell data, it’s “pay first, then unlock.” If you publish media, it can be “pay to license,” with signatures that make the source easy to confirm.
When people can pay in one step using a domain name, they’re more likely to do it. Convenience isn’t fluff here, it’s revenue protection.
This section is short on purpose. Overpromising is how good projects lose trust.
“Permanent” does not mean price stability. Tokens move, fees change, markets cool off, and buyers disappear. A contract can be immutable while demand drops to zero.
“Permanent” also doesn’t mean integrations can’t change. A marketplace can stop supporting a standard. A wallet can change how it resolves names. Communities migrate. If your royalty only works in one place, you don’t have permanence, you have a dependency.
It also doesn’t grant legal immunity. If you’re selling output that risks privacy issues, training disputes, or license conflicts, code won’t protect you. Plain-language disclosures and audit-minded thinking help more than hype.
The biggest failure point is still the private key. Lose it, and your royalty stream can become unreachable. Get phished, and someone can reroute everything.
Smart contracts can also have bugs, and upgrades are a double-edged sword. Upgradeable contracts can fix problems, but they can also weaken trust if users think the rules can be changed at any time.
Name spoofing is another common problem. Lookalike domains can trick users into paying the wrong identity. That’s why your domain should be the single source of truth for payment addresses, and why you should publish verified links and signed messages from the same identity.
A few practical habits reduce risk without adding much friction: multisig for teams, hardware keys for main wallets, public verification posts that never change, and simple monitoring so you notice strange activity quickly.
Claiming a permanent machine intelligence royalty comes down to a simple formula: build a strong onchain identity, attach proof that your machine made the work, publish a clear royalty rule in code, and distribute through channels that respect that rule. The domain is the handle people remember, the wallet is where value lands, and the contract is the payment promise everyone can inspect.
Pick one thing your machine produces, register an onchain identity for it, and set a first royalty rule that’s easy to understand and easy to pay. If the name becomes the trusted anchor, the royalty path has a real chance to last.
