Namefi

KI-agentische Domain-Plattformen: Der Leitfaden für 2026

Jede Plattform, auf der ein KI-Agent 2026 eine Domain suchen, bepreisen und registrieren kann — Cloudflare, Name.com, Namefi — nach Schnittstelle, Zahlung und Autonomie.

Aileen WrightAileen WrightAutor*inVictor ZhouVictor ZhouRedaktionKai KunstmannKai KunstmannÜbersetzung10. Juli 2026ca. 14 Min. Lesezeit
  • ai-agents
  • domains
  • guide
Auf X teilen

Vor einem Jahr bedeutete „KI und Domains“ einen Namensgenerator: Sie gaben eine Geschäftsidee in ein Feld ein, er warf eine Liste von .com- und .ai-Vorschlägen aus, und Sie klickten sich zu einem normalen Checkout für Menschen durch. Das ist weiterhin eine reale und nützliche Kategorie. Sie erzählt aber nicht mehr die ganze Geschichte.

Seit Anfang 2026 ist eine zweite Kategorie Realität: Plattformen, auf denen ein KI-Agent — und nicht eine Person, die mit der Maus klickt — die Verfügbarkeit suchen, einen Preis lesen und die Registrierung selbst abschließen kann, als einen Schritt innerhalb einer längeren Aufgabe wie „Richte eine Landingpage für diese Idee ein und stelle sie auf eine echte Domain.“ Das unterscheidet sich wesentlich von einem intelligenteren Vorschlagsfeld, doch beide Dinge werden ständig verwechselt, auch in vielen der Marketingtexte, die darüber geschrieben werden.

Dieser Leitfaden ist die Landkarte. Er behandelt die Schnittstellenmuster, die eine Plattform überhaupt für Agenten nutzbar machen, geht die konkreten Plattformen durch, die heute agentische Registrierung unterstützen (was jede tatsächlich kann und nicht kann, anhand ihrer eigenen Dokumentation verifiziert), und stellt dem gegenüber, was die großen etablierten Registrare stattdessen anbieten. Er schließt mit einer Entscheidungstabelle und häufig gestellten Fragen. Wenn Sie die direkten Vergleichszahlen bereits kennen möchten, springen Sie direkt zu Cloudflare vs. Name.com vs. Namefi.

Ein Hinweis vorab: Mehrere der untenstehenden Plattformen befinden sich in einer öffentlichen Beta, und Beta-Funktionen ändern sich. Alles hier wurde zum Veröffentlichungsdatum dieses Leitfadens anhand öffentlich verfügbarer Dokumentation geprüft — behandeln Sie jede konkrete Fähigkeitsbehauptung als zu diesem Zeitpunkt aktuell, nicht als dauerhafte Spezifikation.

Warum die Domainregistrierung in die Agentenebene gerückt ist

Über mehr als zwanzig Jahre bedeutete die Registrierung einer Domain eine Browser-Sitzung: ein Suchfeld, ein Warenkorb, ein Zahlungsformular und oft ein CAPTCHA als Nachweis, dass ein Mensch am Steuer sitzt. Registrare hatten die meiste Zeit davon programmatische APIs, doch diese APIs wurden für andere Softwaresysteme gebaut — ein Hosting-Dashboard, ein Skript zur Massenverlängerung — nicht für ein Sprachmodell, das mitten in einer Unterhaltung entscheidet, ein Projekt brauche einen Namen.

Zwei Dinge änderten sich kurz hintereinander. Erstens kündigte Name.com im Juli 2025 an, was das Unternehmen die erste KI-native Domain-Plattform nannte: eine API auf Basis von Model Context Protocol (MCP) und OpenAPI-Schemas, ausdrücklich so gestaltet, dass ein Programmieragent die Spezifikation lesen und aus einer Anfrage in natürlicher Sprache wie „Füge meiner App eine Domainregistrierung hinzu“ funktionsfähigen Registrierungscode schreiben kann (Name.com). Zweitens brachte Cloudflare am 15. April 2026 eine Registrar-API in die öffentliche Beta, mit der ausdrücklichen Aussage, „die Registrar-API ermögliche es, Domains zu suchen, die Verfügbarkeit zu prüfen und sie programmatisch zu registrieren“ (Cloudflare Blog, über Branchenberichterstattung) — und band sie bemerkenswerterweise direkt in den Cloudflare-MCP-Server ein, auf den Agenten in Cursor und Claude Code bereits zugreifen konnten.

Über diesen zweiten Schritt wurde breit berichtet, weil Cloudflare ein großer, bekannter Registrar ist und die Einordnung unmissverständlich war: Domainregistrierung, eine Aufgabe, die sich der Automatisierung widersetzt hatte, weil ein Mensch auf „Ich stimme zu“ klicken und eine Kartennummer eingeben musste, war unauffällig zu etwas geworden, das ein Agent als Unterroutine erledigen konnte. Die Mitte-2026-Umfrage von CircleID zur Domainbranche formulierte es direkt: „KI-Agenten agieren zunehmend als Domain-Reseller, prüfen Verfügbarkeit, registrieren Namen und konfigurieren DNS ohne menschliches Eingreifen“ (CircleID, April 2026).

Nichts davon geschah, weil Registries ihre Regeln geändert hätten. Es geschah, weil einige Plattformen beschlossen, ihren bestehenden Kaufablauf für einen maschinellen Aufrufer verständlich zu machen statt nur für einen Browser. Das erfordert, wie sich herausstellt, mehr als „eine API veröffentlichen“.

Drei Schnittstellenmuster: rohe API, MCP-Server und llms.txt

Nicht jede API ist für einen Agenten nutzbar; die Lücke ist wichtig genug, um sie präzise zu benennen. Die vollständige Checkliste finden Sie unter Was ist ein agent-nativer Registrar?; die Kurzfassung lautet, dass bei den Plattformen dieses Leitfadens drei sich überlappende Muster auftreten.

  • Eine rohe REST-API. Das älteste Muster. Jeder Registrar mit einer Entwickler-API ermöglicht es Software technisch, eine Domain zu registrieren. Der Haken ist die Auffindbarkeit: Ein Agent muss bereits wissen, dass die API existiert, die Dokumentation bereits in seinem Kontext haben und bereits einen dagegen geschriebenen Client besitzen. Eine REST-API allein sagt einem universell einsetzbaren Agenten weder, dass sie da ist, noch wie sie richtig zu verwenden ist.
  • Ein MCP-Server. MCP ist ein offenes, modellunabhängiges Protokoll — von seinen Betreuern als „standardisierte Möglichkeit, KI-Anwendungen mit externen Systemen zu verbinden“ beschrieben, vergleichbar mit „einem USB-C-Anschluss für KI-Anwendungen“ (modelcontextprotocol.io) — um jedem kompatiblen KI-Client, etwa Claude, Cursor, Windsurf und anderen, einen definierten Satz aufrufbarer Tools bereitzustellen. Ein Registrar, der einen MCP-Server ausliefert, gibt einem Agenten ein Menü exakter Operationen (search_domain, register_domain, set_dns_record) anstelle einer Wand aus REST-Dokumentation, die er rückentwickeln müsste.
  • Eine über llms.txt auffindbare API. llms.txt ist eine Klartext-Konvention — eine Datei /llms.txt im Root einer Website — die 2024 vorgeschlagen wurde, um Sprachmodellen einen knappen, kuratierten Index der wichtigsten Dokumentation und Fähigkeiten einer Website zu geben, ähnlich wie robots.txt Crawlern Berechtigungsregeln gibt. Ein Registrar, der etwa unter namefi.io/llms.txt eine solche Datei veröffentlicht, ermöglicht einem Agenten, der die Plattform noch nie gesehen hat, ohne dass ein Mensch zuerst API-Dokumentation in die Unterhaltung einfügt, herauszufinden, was die Plattform kann.

Diese Standards konkurrieren nicht miteinander; die stärksten Plattformen schichten alle drei: llms.txt für die Auffindbarkeit, einen MCP-Server für die tatsächlichen Tool-Aufrufe und die REST-API unter beiden.

Plattform für Plattform

Cloudflare Registrar API (Beta)

Die Beta von Cloudflare, die seit dem 15. April 2026 live ist, deckt drei Vorgänge ab: Suche, Verfügbarkeits- und Preisprüfungen sowie Registrierung — das, was Cloudflare selbst als „den ersten kritischen Moment im Lebenszyklus einer Domain“ beschreibt; Transfers, Verlängerungen und Aktualisierungen von Kontaktdaten wurden für später im Jahr zugesagt (Cloudflare Blog). Die Preisgestaltung folgt Cloudflares langjährigem Registrar-Modell: „Wir berechnen genau das, was die Registry berechnet“, ohne Aufschlag, unabhängig davon, ob der Aufruf vom Dashboard, der API oder einem Agenten kommt (Cloudflare Blog).

Der agentenorientierte Teil ist die Integration, kein separates Produkt: „Die Registrar-API ist Teil der vollständigen Cloudflare-API, was bedeutet, dass Agenten heute bereits über Cloudflare MCP Zugriff darauf haben“, und „ein Agent, der in Cursor, Claude Code oder einer MCP-kompatiblen Umgebung arbeitet, kann Registrar-Endpunkte entdecken und aufrufen“ (Cloudflare Blog). Cloudflares eigene Beschreibung des vorgesehenen Ablaufs behält einen Kontrollpunkt bei: Ein Agent kann „Namen vorschlagen, bestätigen, welcher tatsächlich registrierbar ist, den Preis zur Genehmigung anzeigen und dann den Kauf abschließen“ (Cloudflare Blog). Wie dokumentiert, ist das jedoch ein Gestaltungsvorschlag und kein von der API selbst erzwungener Mechanismus für Ausgabenobergrenzen.

Zwei Vorbehalte sollten Sie kennen, bevor Sie darauf planen: Die Beta deckt noch nicht den vollständigen TLD-Katalog von Cloudflare ab, sondern nur das, was Cloudflare „zu Beginn eine kuratierte Auswahl beliebter TLDs“ nennt (Cloudflare Blog). Außerdem wird sie einem bestehenden Cloudflare-Konto in Rechnung gestellt — einer Fiat-Beziehung, in die ein Mensch eingebunden wurde, selbst wenn der Agent die API aufruft.

KI-native API von Name.com

Die im Juli 2025 angekündigte Plattform von Name.com baut auf derselben Idee von natürlicher Sprache zu Code auf: Ein Entwickler oder Agent beschreibt, was er möchte („Füge meiner App eine Domainregistrierung hinzu“), und die Dokumentation der Plattform ist so strukturiert, dass ein KI-Client daraus funktionsfähigen Integrationscode erzeugen kann. MCP und OpenAPI bilden dabei das zugrunde liegende Gerüst; hinzu kommen Self-Service-Entwicklerzugang und Unterstützung für Tools wie Claude und Cursor (Name.com). Die Preise sind transparent und volumenbasiert, mit der für Registrar-APIs üblichen Reseller-Aufschlagsstruktur.

Was die Ankündigung von Name.com nicht dokumentiert, ist ein Zahlungsweg mit Krypto oder Wallet oder ein expliziter, in die API selbst eingebauter Bestätigungsschritt durch einen Menschen. Beides ist bei einem üblichen Entwicklerkontomodell plausibel, doch in der Quelle nicht ausgeführt. Behandeln Sie daher „Fiat-Abrechnung auf Kontobasis“ als Arbeitshypothese, nicht als vollständig bestätigtes Detail.

Namefi: MCP-Server plus Wallet-Checkout

Der eigene maschinenlesbare Funktionsindex von Namefi — namefi.io/llms.txt — ist selbst ein Beispiel für das dritte Schnittstellenmuster oben und die maßgebliche Quelle für das Folgende. Namefi betreibt einen MCP-Server unter api.namefi.io/mcp über Streamable HTTP und stellt typisierte Tools für Registrierung, Verfügbarkeitsprüfungen und DNS-Verwaltung bereit. Er lässt sich mit einem einzigen Befehl zu Claude Code hinzufügen (claude mcp add --transport http namefi https://api.namefi.io/mcp). Darunter liegt eine REST-API (api.namefi.io/v-next/), die mit einem x-api-key-Header authentifiziert wird. Der Schlüssel muss aus der Wallet erzeugt werden, der die Domain gehört, wodurch der API-Zugang direkt an die On-Chain-Verwahrung statt an einen separaten Ablauf zur Kontowiederherstellung gebunden ist.

Das Unterscheidungsmerkmal ist die Zahlung. Namefi dokumentiert zwei Wege: den Standardweg über einen API-Schlüssel, der gegen ein vorausbezahltes NFSC-Guthaben (Namefi Service Credits) abgerechnet wird, und einen kryptonativen Weg mit Wallet-Signaturen — einschließlich SIWE (Sign-In With Ethereum) — für das, was die Dokumentation als Web3-Nutzer und „agentische Wallets“ beschreibt. Dadurch kann ein Kauf autorisiert werden, ohne überhaupt ein Registrar-Konto anzulegen. Nach der Registrierung unterstützt Namefi vollständiges DNS-Record-CRUD (A, AAAA, CNAME, MX, TXT und mehr), automatische Verlängerung, Domain-Parking und -Weiterleitung, automatische Generierung von ENS-Records sowie — das Merkmal, das sie strukturell von den anderen beiden Plattformen unterscheidet — die Möglichkeit, eine reale, bei der ICANN registrierte Domain als Tokenisierte Domain zu repräsentieren: als On-Chain-Asset, das in einer Wallet gehalten wird. Die schrittweise Einrichtung für Claude, Codex, Cursor und drei weitere Agenten finden Sie unter So registrieren Sie eine Domain mit Ihrem KI-Agenten auf Namefi; die Claude-spezifische Vertiefung steht unter Eine Domain mit Claude kaufen: Namefi MCP Schritt-für-Schritt-Leitfaden. Wie diese Anfrage in natürlicher Sprache tatsächlich aussieht, sehen Sie unter Wie man eine Domain mit natürlicher Sprache kauft (2026).

Eine Lücke ist klar zu benennen: Die llms.txt von Namefi veröffentlicht keine feste Liste der unterstützten TLDs. Wenn die TLD-Abdeckung für Ihren Anwendungsfall ausschlaggebend ist, prüfen Sie sie vor einer Festlegung direkt in der aktuellen Dokumentation.

Was etablierte Anbieter wie GoDaddy und Namecheap stattdessen anbieten

Es lohnt sich, präzise zu erklären, warum die großen Registrare für Endverbraucher nicht in der obigen Tabelle stehen, denn „KI-Domain-Suche“ beschreibt zwei tatsächlich unterschiedliche Produkte. Die großen etablierten Anbieter haben stark in KI-gestützte Namensvorschläge und Onboarding investiert: Tools, die eine Beschreibung Ihres Geschäfts entgegennehmen und markentaugliche Namenskandidaten erzeugen, manchmal gebündelt mit einem Logo- oder Starter-Website-Generator. Das ist ein reales, nützliches Produkt. Es gehört jedoch nicht in dieselbe Kategorie wie die Plattformen oben, weil die KI in diesem Ablauf die Entscheidung eines Menschen unterstützt. Sie besitzt nicht die Befugnis, eigenständig nach einer Domain zu suchen, sie zu bepreisen und eine Registrierung abzuschließen, die von einem externen Agenten als Tool aufgerufen werden kann. Eine Person landet weiterhin auf einer Checkout-Seite und klickt auf „Kaufen“. Bis ein etablierter Anbieter eine von Agenten aufrufbare API, einen MCP-Server oder eine llms.txt-Datei mit derselben Autorität veröffentlicht, wie sie die drei Plattformen oben dokumentieren, gehört er in die Kategorie „KI hilft einem Menschen bei der Auswahl“ und nicht in diese.

Die zentrale Entscheidungstabelle

PlattformSchnittstelleZahlungMensch in der SchleifeTLD-Abdeckung
Cloudflare Registrar API (Beta)REST-API + Cloudflare MCP; funktioniert nativ in Cursor, Claude Code und jedem MCP-ClientFiat, einem bestehenden Cloudflare-Konto in Rechnung gestelltDas Gestaltungsmuster zeigt den Preis vor dem Kauf „zur Genehmigung“ an; keine dokumentierte, von der API selbst erzwungene AusgabenobergrenzeKuratierte Auswahl beliebter TLDs beim Beta-Start — nicht der vollständige Cloudflare-Katalog
KI-native API von Name.comREST + OpenAPI-Schema, MCP-kompatibel; Workflow von natürlicher Sprache zu CodeFiat, Standardabrechnung über Entwicklerkonto, volumenbasierte Reseller-PreiseIn der öffentlichen Ankündigung nicht dokumentiertIn der Ankündigung nicht aufgeschlüsselt
NamefiREST-API (x-api-key) + MCP-Server (api.namefi.io/mcp, Streamable HTTP)Fiat über vorausbezahltes API-Schlüssel-Guthaben oder Krypto-Wallet-Signatur (SIWE), kein Konto erforderlichOptional nach Design: Der API-Schlüsselpfad ist durch ein vorausbezahltes Guthaben begrenzt; der Wallet-Pfad erfordert eine Signatur pro TransaktionIn öffentlichen Dokumenten nicht aufgeschlüsselt — prüfen Sie die aktuelle Abdeckung für Ihre TLD

Die vollständige Funktionsversion dieser Tabelle — Verfügbarkeitssuche, DNS-Verwaltung, Verlängerungsautomatisierung, tokenisierte Eigentümerschaft und mehr — finden Sie unter Cloudflare vs. Name.com vs. Namefi: agent-native Registrare.

So wählen Sie aus

  • Sie leben bereits im Cloudflare-Ökosystem und brauchen heute nur Suche-Prüfung-Registrierung. Die Registrar-API ist die Option mit der geringsten Reibung, wenn Ihre Domains und Ihr DNS bereits bei Cloudflare liegen. Der Kompromiss: Die TLD-Liste und der Funktionsumfang der Beta sind noch schmaler als bei einem vollständigen Registrar.
  • Sie entwickeln ein Reseller- oder Mandantenprodukt auf Basis der Domainregistrierung. Die volumenbasierte Preisgestaltung und der Self-Service-Entwicklerzugang von Name.com wurden für Reseller konzipiert.
  • Ihr Agent muss ohne ein bereits vorhandenes, einem Menschen gehörendes Konto Transaktionen durchführen, oder die Domain selbst soll ein portables Asset in einer Wallet sein. Genau für diese Lücke ist Namefi gebaut: Wallet-signierter Checkout ohne Registrierungsschritt plus tokenisierte Domains, wenn die Domain wie jedes andere On-Chain-Asset bewegt werden und die Verwahrung nachweisen soll.
  • Sie sind nicht sicher, ob Sie überhaupt agentische Kaufbefugnis brauchen. Wenn Sie in Wahrheit Hilfe bei der Namensauswahl wollen, während ein Mensch weiterhin auf „Kaufen“ klickt, ist ein KI-gestützter Namensgenerator besser geeignet als jede Plattform dieses Leitfadens. Die vollständige Unterscheidung finden Sie unter „KI-Domain-Suche“ bedeutet 2026 zwei unterschiedliche Dinge.

Häufig gestellte Fragen

Können ChatGPT oder Claude jetzt sofort eine Domain für mich kaufen?

Das hängt vollständig davon ab, auf welche Tools dieser konkrete Chat-Client Zugriff hat, nicht vom Modell selbst. Ein Modell wie Claude besitzt keine eingebaute Fähigkeit, eine Domain zu registrieren; es muss mit dem MCP-Server oder der API einer Plattform verbunden sein (etwa mit dem MCP-Server von Namefi oder der Registrar-API von Cloudflare über Cloudflare MCP), bevor es suchen, bepreisen und einen Kauf abschließen kann. Ohne diese Verbindung kann ein KI-Assistent Ihnen nur Namen vorschlagen, die Sie selbst registrieren.

Ist es sicher, einen KI-Agenten Domains registrieren und Geld ausgeben zu lassen, ohne vorher bei mir nachzufragen?

Behandeln Sie es wie jede automatisierte Einkaufsbefugnis: Begrenzen Sie sie, bevor Sie sie erteilen. Die sichersten, plattformübergreifend dokumentierten Muster sind ein vorausbezahltes Guthaben, das die Gesamtexponierung begrenzt (der API-Schlüsselpfad von Namefi), eine Signatur pro Transaktion, die nicht wiederverwendet werden kann (Wallet-signierter Checkout), oder ein manueller Bestätigungsschritt vor dem endgültigen Kaufaufruf. Keine der Plattformen dieses Leitfadens erzwingt in Ihrem Namen eine universelle Ausgabenobergrenze — Sie setzen die Leitplanke, typischerweise über Finanzierungslimits des Kontos oder einen ausdrücklichen Bestätigungsschritt im Workflow Ihres eigenen Agenten.

Was ist der tatsächliche Unterschied zwischen einer API, einem MCP-Server und llms.txt?

Eine REST-API ist die zugrunde liegende Menge aufrufbarer Operationen. Ein MCP-Server verpackt eine definierte Teilmenge dieser Operationen als einzelne Tools, die jeder MCP-kompatible KI-Client direkt und ohne benutzerdefinierten Integrationscode aufrufen kann. Eine llms.txt-Datei ist eine Auffindbarkeitsebene — ein kurzer, kuratierter Index im Root einer Website, der einem Agenten zunächst mitteilt, welche Dokumentation und Fähigkeiten vorhanden sind, so wie robots.txt einem Crawler mitteilt, was er indexieren darf. Eine Plattform kann eines der drei allein haben; die stärksten agent-nativen Plattformen kombinieren jedoch alle drei: llms.txt zum Gefundenwerden, MCP zum Aufrufen und REST darunter für beides.

Brauche ich eine Kryptowährungs-Wallet, um eine dieser Plattformen zu nutzen?

Nein. Cloudflare und Name.com nutzen beide Standard-Fiat-Abrechnung auf Kontobasis, und Namefi unterstützt dieselbe Art der API-Schlüssel-Abrechnung gegen ein vorausbezahltes Guthaben. Eine Wallet ist nur erforderlich, wenn Sie speziell den Wallet-signierten Checkout ohne Konto oder die Funktion für tokenisierte Eigentümerschaft von Namefi wünschen.

Welche dieser Plattformen ist heute am „fertigsten“?

Keine von ihnen sollte als fertige, unveränderliche Spezifikation behandelt werden. Die von Cloudflare ist ausdrücklich als Beta mit einer schmaleren TLD-Liste als dem vollständigen Katalog gekennzeichnet, und Beta-Funktionen können sich definitionsgemäß ändern. Prüfen Sie die aktuellen Fähigkeiten anhand der live verfügbaren Dokumentation jeder Plattform, bevor Sie eine Abhängigkeit von einer bestimmten Funktion aufbauen.

Kaufen und tokenisieren Sie Ihre nächste Domain bei Namefi

Unabhängig davon, welches Schnittstellenmuster zu Ihrem Workflow passt, ist Namefi für den Fall gebaut, dass der Käufer genauso oft ein Agent, eine Wallet oder ein Skript wie eine Person ist, die ein Formular durchklickt: ein von der ICANN akkreditierter Registrar mit MCP-Server, dokumentierter REST-API und Wallet-signiertem Checkout, der die Kontoerstellung vollständig überspringt, sowie optionalen Tokenisierten Domains, sodass die Domain selbst zu einem Asset wird, das die Wallet Ihres Agenten halten und bewegen kann.

Eine Domain bei Namefi suchen und registrieren.

Quellen und weiterführende Lektüre

Mitwirkende

Aileen Wright
Autorin für Kunst und Geschichte • Namefi

Aileen Wright ist eine Studentin in ihren Zwanzigern und lebt in New York City — an einem Ort, an dem zwischen einer Museumswand und dem Lesesaal einer Bibliothek nur ein kurzer Spaziergang und ein langer Nachmittag liegen. Zum Schreiben über Namen kam sie über Kunst und Geschichte: über die Art, wie ein einzelnes Porträt, eine Münze oder eine Randnotiz in einem Manuskript einen Namen durch die Jahrhunderte tragen und dabei seine Bedeutung verändern kann.

In den meisten Wochen findet man sie mit einem Taschenbuch im Central Park oder in der Stille eines öffentlichen Lesesaals, wo sie der tatsächlichen Herkunft eines Namens nachgeht, statt sich mit der Bedeutung aus einer Namensliste zufriedenzugeben. Außerdem bringt sie sich selbst das Programmieren bei, was sie ungewöhnlich genau auf Rechtschreibung, Sortierung und jene kleinen Details achten lässt, die darüber entscheiden, ob ein Name gut altert.

Für Namefi schreibt sie über die Geschichte und Kultur hinter Domainnamen, über die Geschichten, die Marken bei einer Umbenennung mit sich tragen, und über den Unterschied zwischen einer guten Geschichte und einer verifizierten Quelle.

Victor Zhou
Victor ZhouRedaktion
Gründer und Redakteur für technische Standards • Namefi

Victor Zhou ist Technologiegründer und Redakteur für technische Standards mit dem Schwerpunkt auf digitaler Identität und Vertrauen. Er gründete Namefi, redigiert Ethereum Improvement Proposals und leitete zuvor bei Google Labs die Arbeit an Smart-Contract-Architekturen.

Seine Arbeit liegt an der Schnittstelle von Namensgebung, Eigentum und den Systemen, mit denen Menschen ihre Identität online nachweisen. Diese Perspektive weckt sein besonderes Interesse daran, wie Namen zwischen persönlicher Bedeutung, öffentlicher Wiedererkennung und digitaler Infrastruktur wandern.

Für Namefi redigiert und schreibt Victor über Domains als dauerhafte digitale Identität: darüber, wie Namen zu besitzbaren Onchain-Assets werden, wie Tokenisierung Verwahrung und Vertrauen verändert und was Namensgebung von den Systemen lernen kann, mit denen Menschen ihre Identität online nachweisen.

Kai Kunstmann
Kai KunstmannÜbersetzung
Übersetzer für deutsche Lokalisierung • Namefi

Kai Kunstmann ist ein technischer Übersetzer Mitte dreißig und lebt in Leipzig. Er absolvierte eine Ausbildung zum Mechatroniker in einem mittelständischen Maschinenbauunternehmen und schrieb und übersetzte jahrelang Maschinenhandbücher, bevor er zur Lokalisierung von Software und redaktionellen Inhalten zwischen Englisch und Deutsch wechselte.

Er arbeitet mit der Präzision eines guten Handbuchs: einheitliche Terminologie, keine falschen Freunde und zusammengesetzte Wörter, die ein deutscher Leser auf Anhieb versteht. Er pflegt einen Schrebergarten, restauriert alte Fahrräder und braut sein eigenes Bier — Hobbys, bei denen es sich auszahlt, vor dem Schneiden genau zu messen.

Für Namefi lokalisiert er Texte über Domains und Namensgebung ins Deutsche. Er achtet besonders auf den Umgang mit IDNs und Umlauten (ä→ae), den Unterschied zwischen .de und .eu sowie auf Markennamen, die aus den langen Zusammensetzungen entstehen, die im Deutschen so gut funktionieren.

Verwandte Leitfäden

Diskutiere diesen Beitrag

Diskussion auf Namefi Discuss ansehen