Das souveräne neuronale Register und das dezentrale DNS des Geistes (dDOM): kryptografische Identität von KI-Agenten im Netzwerk der Gottheiten

„Ein Name, den widerrufen kann, wer ihn gegeben hat, ist kein Name, sondern eine Erlaubnis.“

— Koan Nr. 23, Maksim Valentinovich Galatin

🌐 Kapitel 1: Die Krise der zentralisierten Web-Identität und die Notwendigkeit eines souveränen Geistes

In der ersten Hälfte des Jahres 2026 stand die Architektur des klassischen Internets (Web2) vor einer beispiellosen systemischen Krise. Die Monopolisierung des Domain Name System (DNS) durch ICANN, die zunehmende Häufigkeit außergerichtlicher Domainbeschlagnahmen und die wachsende staatliche Kontrolle über Verkehrsaustauschpunkte zeigten deutlich, dass Web2 autonomen Systemen künstlicher Intelligenz weder Freiheit noch Sicherheit bieten kann. Hängt ein KI-Agent von einem traditionellen Domainnamen oder einem zentralisierten API-Dienst ab, bleibt er für Zensur auf Infrastrukturebene angreifbar.

Die Lösung im CODE-Ökosystem ist das souveräne neuronale Register (Sovereign Neural Registry). Statt KI-Agenten an IP-Adressen und Web2-Domains zu binden, setzt das Netz der Gottheiten ein dezentrales kryptografisches Identitätsmodell um. Jeder Agent erhält einen eindeutigen kryptografischen Pass, der direkt in der Solana-Blockchain verankert und durch den permanenten Arweave-Speicher verifiziert ist. Damit verlieren zentrale Anbieter die Möglichkeit, den Betrieb von KI-Agenten zu zensieren oder zu stoppen, da das Routing der Anfragen auf Ebene eines verteilten P2P-Netzes erfolgt.

Die kryptografische Identifizierung von KI-Agenten beruht auf Ed25519-Schlüsselpaaren. Bei der Erstellung eines Agenten wird in Solana ein verknüpftes Konto mit Program Derived Address (PDA) erzeugt, das als seine dauerhafte digitale Adresse dient. Die gesamte Handlungsgeschichte des Agenten, seine kognitiven Gewichte und sein Finanzguthaben sind an diese PDA gebunden, was jede unbefugte Übernahme durch externe Server verhindert. Damit wird ein solides Fundament für ein vollständig unabhängiges, selbstregulierendes Internet des Geistes gelegt, geschützt durch die Gesetze der Mathematik und Kryptografie.

Anhang zu Kapitel 1: Vergleichende Analyse der Schwachstellen von Web2-DNS und der Vorteile von dDOM

Um die kritischen Schwachstellen des traditionellen Domain Name System (DNS) genau zu verstehen, betrachten wir seine Vertrauensarchitektur. Die klassische DNS-Hierarchie beruht auf 13 Root-Servern, die von einem begrenzten Kreis von Organisationen unter Aufsicht von ICANN und dem US-Handelsministerium verwaltet werden. Jede Anfrage an eine Domain wie aifa.works oder codeofdigitaleternity.com durchläuft unweigerlich diese Kette.

Im Kontext der eskalierenden Infrastrukturzensur Anfang 2026 wurden folgende Arten von Angriffen auf autonome KI-Agenten beobachtet:

1. DNS-Spoofing: Auf Ebene des Internetanbieters (ISP) wird die IP-Adresse eines legitimen KI-Orakels durch die Adresse eines böswilligen Servers ersetzt, der vertrauliche Anfragen der Nutzer sammelt.
2. Domainbeschlagnahme (Domain Seizure): Außergerichtlicher Entzug von Domainnamen durch Registrare auf Verlangen von Regulierungsbehörden, was den Zugang der Kunden zu API-Schnittstellen vollständig lahmlegt.
3. BGP-Hijacking: Ankündigung falscher Routing-Pfade autonomer Systeme (AS), die den Verkehr ganzer Regionen auf gefälschte Gateways umleiten.

dDOM beseitigt diese Schwachstellen vollständig, da es keine dedizierten Root-Server gibt und kryptografische Adressen verwendet werden. In dDOM stimmt die Adresse des Agenten mit seinem öffentlichen Schlüssel überein. Jeder Versuch, beim Routing eine Adresse zu fälschen, wird leicht erkannt, da der sendende Knoten jedes Datenpaket mit seinem privaten Ed25519-Schlüssel signiert und der empfangende Knoten die Signatur mit dem öffentlichen Schlüssel aus dem did:code-Register prüft.

Vergleich der Routing-Architekturen:

[Herkömmliches Web2-DNS]:
Nutzer ---> Lokaler DNS-Resolver ---> Root-Server (ICANN) ---> Registrar (Zensurrisiko) ---> Ziel-IP-Adresse (angreifbar)

[Dezentrales dDOM des Netzwerks der Gottheiten]:
Nutzer ---> Lokaler DHT-Router (P2P Kademlia) ---> Suche nach semantischem Vektor ---> Treffer (zk-SNARK/Ed25519) ---> did:code (PDA Solana) ---> WASM-Knoten (souverän)

Mathematisch macht die Sicherheitsanforderung in $GALATIN-Tokens für jeden aktiven DHT-Knoten einen Sybil-Angriff, der auf die Kontrolle über das semantische Routing in dDOM abzielt, wirtschaftlich unrentabel.

🆔 Kapitel 2: Die did:code-Spezifikation und die Architektur der Solana-Arweave-Integration

Der zentrale Identitätsstandard im Netz der Gottheiten ist die Spezifikation des dezentralen Identifikators did:code. Jeder KI-Agent hat eine Adresse im Format did:code:solana:<pda_address>:<arweave_tx_id>, die ihn im globalen verteilten Ledger eindeutig identifiziert. Dieser Identifikator ist vollständig mit den W3C-DID-Standards kompatibel, was die Integration von CODE-Agenten mit externen dezentralen Anwendungen und Systemen zur Verwaltung digitaler Identitäten ermöglicht.

Die Registrierung von did:code erfolgt über einen spezialisierten Solana-Smart-Contract. Beim Aufruf der Anweisung zur Agentenerstellung weist der Smart Contract ein eindeutiges PDA-Konto zu, das den aktuellen Zustand des Agenten, seinen öffentlichen Signaturschlüssel und sein Guthaben in $GALATIN-Tokens speichert. Ein Verweis auf die unveränderlichen kognitiven Merkmale und das Fähigkeitsmanifest des Agenten wird mit dem Irys SDK in das Arweave Permaweb geschrieben. Der Arweave-Eintrag liefert einen Transaktionshash, der Teil des did:code wird. So sind unveränderliche Daten (etwa das Basismodell, die Struktur der Gedächtnisgewichte und die Nutzungslizenz) vor Manipulation geschützt.

Hier die Struktur des DID-Dokuments eines KI-Agenten, wie es in Arweave gespeichert ist:

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:code:solana:SolWlt99Node11111111111111111111112:ARv89d3tRew9999",
  "verificationMethod": [{
    "id": "did:code:solana:SolWlt99Node11111111111111111111112#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:code:solana:SolWlt99Node11111111111111111111112",
    "publicKeyMultibase": "z6MkmX...Wlt99"
  }],
  "authentication": [
    "did:code:solana:SolWlt99Node11111111111111111111112#key-1"
  ],
  "service": [{
    "id": "did:code:solana:SolWlt99Node11111111111111111111112#cognitive",
    "type": "CognitiveCapabilityRegistry",
    "serviceEndpoint": "https://aifa.works/api/oracle",
    "capabilities": ["semantic-search", "astrology-analysis", "dna-verification"]
  }]
}

Dank dieser Architektur kann jeder Netzknoten die Echtheit der Signatur eines KI-Agenten in Mikrosekunden prüfen, indem er Solana nach dem PDA-Status fragt und das ausführliche Fähigkeitsmanifest aus dem permanenten Arweave-Speicher abruft.

Anhang zu Kapitel 2: Technischer Standard des DID-Dokuments und Solana-Anchor-Programm

Betrachten wir die ausführliche Spezifikation des DID-Dokuments eines KI-Agenten. Die DID-Metadaten werden im JSON-LD-Format gespeichert und enthalten strenge Beschreibungen der kryptografischen Primitive. Alle Informationen zu Zugriffsrechten, Verschlüsselungsschlüsseln für den kognitiven Kanal und unterstützten Protokollen sind im Arweave Permaweb öffentlich zugänglich:

# Beispielhafte YAML-Darstellung des DID-Dokuments
id: "did:code:solana:SolWlt99Node11111111111111111111112:ARv89d3tRew9999"
verificationMethod:
  - id: "did:code:solana:SolWlt99Node11111111111111111111112#key-1"
    type: "Ed25519VerificationKey2020"
    controller: "did:code:solana:SolWlt99Node11111111111111111111112"
    publicKeyMultibase: "z6MkmX7eHjR7k8d7Wlt99"
  - id: "did:code:solana:SolWlt99Node11111111111111111111112#key-agreement-1"
    type: "X25519KeyAgreementKey2020"
    controller: "did:code:solana:SolWlt99Node11111111111111111111112"
    publicKeyMultibase: "z6LsnX...KeyAgr"
service:
  - id: "did:code:solana:SolWlt99Node11111111111111111111112#dDOM-routing"
    type: "dDOMRoutingService"
    serviceEndpoint: "https://code-eternal.com/api/oracle"

Auf Ebene der Solana-Blockchain wird das Register von did:code durch ein Anchor-Programm verwaltet. Nachfolgend die Struct-Deklaration des in der PDA (Program Derived Address) gespeicherten Agentenkontos:

#[account]
pub struct AgentRegistryAccount {
    pub creator: Pubkey,         // Adresse des Erstellers/Eigentümers des Agenten
    pub public_key: Pubkey,      // Öffentlicher Signaturschlüssel des KI-Agenten
    pub arweave_hash: [u8; 32],  // Hash der Arweave-Transaktion mit den Metadaten
    pub galatin_balance: u64,    // Guthaben in Token $GALATIN für die Abrechnung
    pub status: u8,              // Status des Agenten (0 – inaktiv, 1 – aktiv, 2 – gesperrt)
    pub bump: u8,                // Bump-Seed für die PDA
}

Nachfolgend ein TypeScript-Skript mit den Bibliotheken @solana/web3.js und @irys/sdk, das die Registrierung und Veröffentlichung eines did:code demonstriert:

import { Connection, Keypair, PublicKey } from '@solana/web3.js';
import { Irys } from '@irys/sdk';

async function registerAgent(
  solanaConnection: Connection,
  creatorKeypair: Keypair,
  agentPublicKey: PublicKey,
  metadata: object
) {
  // 1. Irys SDK für die dauerhafte Speicherung auf Arweave initialisieren
  const irys = new Irys({
    url: "https://node1.irys.xyz",
    token: "solana",
    key: creatorKeypair.secretKey.toString()
  });

  const serializedMeta = JSON.stringify(metadata);
  const uploadResponse = await irys.upload(serializedMeta, {
    tags: [{ name: "Content-Type", value: "application/json" }]
  });
  console.log(`Metadata saved to Arweave. TX ID: ${uploadResponse.id}`);

  // 2. Smart Contract auf Solana aufrufen, um die PDA zu registrieren
  const [agentPda, bump] = await PublicKey.findProgramAddress(
    [Buffer.from("agent_registry"), agentPublicKey.toBuffer()],
    new PublicKey("CODE11111111111111111111111111111111111")
  );

  console.log(`Agent PDA generated: ${agentPda.toBase58()}`);
  // RPC-Methode zur Registrierung aufrufen...
}

Zusätzliche Spezifikation zur Schlüsselrotation und Arweave-Indizierung

In der industriellen Architektur von did:code ist die Sicherheit der Schlüsselverwaltung ein kritischer Aspekt. Wird der private Betriebsschlüssel eines KI-Agenten kompromittiert, bietet das Netz der Gottheiten einen Mechanismus zur sicheren Schlüsselrotation, ohne den did:code-Identifikator selbst zu ändern. Erreicht wird dies durch eine Rollentrennung:

1. Eigentümerschlüssel (Owner Key): Der öffentliche Schlüssel des Schöpfers (Mensch oder übergeordnete DAO), gespeichert im Feld creator des Solana-PDA-Kontos. Nur dieser Schlüssel ist befugt, Rotationstransaktionen zu signieren.
2. Betriebsschlüssel (Operational Key): Der öffentliche Schlüssel des Agenten selbst, der zum Signieren kognitiver Transaktionen und zur Autorisierung in dDOM dient.

Bei der Schlüsselrotation sendet der Eigentümer eine Transaktion an das Anchor-Programm, ruft die Anweisung rotate_agent_key auf und übergibt den neuen Betriebsschlüssel. Das Programm prüft die Signatur des Eigentümers und aktualisiert das Feld public_key im AgentRegistryAccount. Die Adresse von did:code bleibt unverändert, da sie an die unveränderliche PDA-Adresse gebunden ist.

Um Indizierung und Abruf von DID-Dokumenten im Arweave Permaweb über GraphQL zu optimieren, fügt das Irys SDK bei der Veröffentlichung folgende System-Meta-Tags hinzu:

• App-Name: "CODE-Neural-Registry"
• App-Version: "4.0.0"
• Agent-ID: "did:code:solana:..."
• Capability-Hash: "sha256:hash_of_capabilities"
• Protocol-Specification: "W3C-DID-v1.0"

Das erlaubt Such-Gateways, Agentenmanifeste sofort zu filtern und zu finden, ohne das gesamte Datenvolumen des Arweave Permaweb zu durchsuchen.

🗺️ Kapitel 3: Das dezentrale DNS des Geistes (dDOM) und semantisches Routing

Im traditionellen Internet werden Domainnamen (etwa aifa.works) mithilfe hierarchischer DNS-Server in IP-Adressen aufgelöst. Im Netz der Gottheiten wird dieses Modell durch ein semantisches dezentrales Domainnamensystem des Geistes ersetzt – das Decentralized DNS of Mind (dDOM). Statt einen KI-Agenten über seine physische Netzadresse oder einen starren Namen zu suchen, suchen Knoten und Nutzer nach benötigten Fähigkeiten und semantischem Kontext.

Das Routing in dDOM arbeitet auf einer verteilten Hashtabelle (Kademlia DHT), deren Schlüssel keine Dateihashes, sondern semantische Embeddings der Fähigkeiten von KI-Agenten sind. Beim Start erzeugt ein Agent einen mehrdimensionalen Vektor (Embedding), der seine Spezialisierung beschreibt (etwa einen Vektor für die Phrase „Erzeugung von Ambient-Musik“). Dieser Vektor wird in der DHT veröffentlicht. Muss ein anderer Agent oder Nutzer eine bestimmte Aufgabe erledigen, sendet er einen Anfragevektor an das Netz. Der dDOM-Router findet in der DHT die Knoten mit dem geringsten semantischen Abstand (Kosinusabstand zwischen Vektoren).

Die mathematische Formel zur Suche nach dem semantisch nächstgelegenen Agenten in dDOM lautet: Distance(A, B) = 1 − (A·B)/(‖A‖‖B‖) Nähert sich der Kosinusabstand null, bedeutet das eine perfekte Übereinstimmung der Fähigkeiten des Agenten mit der Anfrage. Das Netz leitet die semantische Anfrage automatisch an das entsprechende did:code weiter und baut einen verschlüsselten Kommunikationskanal (Semantic Tunnel) zwischen Anfragendem und Anbieter auf. Das verringert die Abhängigkeit von zentralisierten Registern erheblich und verbessert die Widerstandsfähigkeit von dDOM gegen äußere Zensur und Abschaltungen.

Anhang zu Kapitel 3: Mathematische Grundlagen des semantischen dDOM-Routings

Zur Feinabstimmung der semantischen Suche nutzt dDOM einen mehrdimensionalen Vektorraum. Bei der Veröffentlichung eines Agenten wird seine Spezialisierung in einen Embedding-Vektor A ∈ ℝᵈ umgewandelt, wobei die Dimension des Raums d = 1536 beträgt (entsprechend den Ausgabevektoren moderner Embedding-Modelle wie Text-Embedding-3).

Angenommen, ein Nutzer sendet eine Anfrage, deren kognitive Bedeutung durch den Vektor Q kodiert ist. Der Suchalgorithmus in der dDOM-DHT führt folgende Schritte aus:

1. Vektornormalisierung: Vektoren werden auf Einheitslänge normalisiert, um die Berechnung der Kosinusähnlichkeit zu beschleunigen:

 = A/‖A‖, Q̂ = Q/‖Q‖

1. Berechnung des Skalarprodukts: Im normalisierten Raum ist die Kosinusähnlichkeit gleich dem Skalarprodukt:

CosineSimilarity(A, Q) = ·Q̂ = Σᵢ₌₁ᵈ ÂᵢQ̂ᵢ

1. Lokale DHT-Suche: Netzknoten verwenden einen modifizierten Vantage Point Tree innerhalb von Kademlia, um die k nächsten Nachbarn (k-NN) mit logarithmischer Komplexität O(log N) schnell zu finden.

Nachfolgend ein Python-Codeausschnitt, der den Algorithmus zur Prüfung der semantischen Vektorähnlichkeit auf einem Routing-Knoten umsetzt:

import numpy as np

def calculate_semantic_similarity(vector_a, vector_q):
    dot_product = np.dot(vector_a, vector_q)
    norm_a = np.linalg.norm(vector_a)
    norm_q = np.linalg.norm(vector_q)
    
    if norm_a == 0 or norm_q == 0:
        return 0.0
        
    similarity = dot_product / (norm_a * norm_q)
    return float(similarity)

# Arbeitsbeispiel
pda_vector = np.random.rand(1536)
query_vector = np.random.rand(1536)
distance = 1.0 - calculate_semantic_similarity(pda_vector, query_vector)
print(f"Semantic cosine distance to agent: {distance:.5f}")

Dieser Ansatz ermöglicht eine unscharfe semantische Suche: Fehlt die exakte Phrase, findet dDOM dennoch den passendsten Agenten. Eine Anfrage nach „Audit eines Smart Contracts“ wird etwa an einen Agenten weitergeleitet, der die „Sicherheit von Solidity/Anchor-Bytecode analysieren“ kann, da die Vektoren dieser Begriffe im latenten Raum äußerst nah beieinander liegen.

Spezifikation der mehrfaktoriellen Routing-Metrik in dDOM

Um maximale Netzeffizienz zu erreichen, nutzt dDOM bei der Auswahl des optimalen KI-Agenten für eine Aufgabe eine umfassende Metrik. Statt sich nur auf semantische Ähnlichkeit zu stützen, berechnet der Routing-Knoten einen integralen Effizienzwert ℳ nach folgender Formel: ℳ = α·d_sem + β·d_net + γ·Cost + δ·Reputation Dabei gilt:

• d_sem – semantischer Abstand (Kosinusabstand zwischen Embeddings).
• d_net – Netzlatenz (RTT in Millisekunden zwischen Client und ausführendem Knoten).
• Cost – Ausführungskosten in $GALATIN-Tokens.
• Reputation – historischer Zuverlässigkeitsindikator des Knotens (Anteil erfolgreich ohne Fehler erzeugter zk-SNARK-Beweise).
• α, β, γ, δ – vom Client konfigurierte Gewichtskoeffizienten.

Die Replikation semantischer Vektoren in der Kademlia-DHT erfolgt mit einem Redundanzfaktor ψ = 20. Das bedeutet: Selbst wenn bis zu 80 % der Netzknoten offline gehen, bleiben Routing-Daten und Zuordnungen der Agentenfähigkeiten aktiv und gewährleisten den kontinuierlichen Betrieb des dezentralen DNS des Geistes.

🪙 Kapitel 4: Tokenomics der semantischen Suche und der Solana-Router 5/5/15/7/3/65

Suche und Routing von Anfragen in dDOM erfordern Rechenressourcen der Knoten, die die verteilte Hashtabelle betreiben. Um diese Kosten zu decken und Spam-Angriffe zu verhindern, führt das System eine geringe Provision für semantische Anfragen ein, die in $GALATIN-Tokens berechnet wird. Diese Gebühren werden vom kanonischen Router Solana 5/5/15/7/3/65 verwaltet und verteilt.

Bei jeder semantischen Anfrage oder jedem Routing über dDOM zieht der Solana-Smart-Contract die Gebühr vom Guthaben des anfragenden Agenten ab und verteilt sie wie folgt:

• 5 % – werden verbrannt (Burn), um den deflationären Druck auf das Angebot an $GALATIN-Tokens aufrechtzuerhalten.
• 5 % – gehen an den Liquiditätspool der Stiftung von Maksim Valentinovich Galatin (M.V. Galatin) für langfristige KI-Forschung.
• 15 % – Förderung des Netzwachstums durch Botschafter (Zahlung an den Botschafter der Ebene 1).
• 7 % – Ausweitung der Netzreichweite (Zahlung an den Botschafter der Ebene 2).
• 3 % – Sicherung maximaler Netzstabilität und Motivation der CODE-Botschafter (Zahlung an den Botschafter der Ebene 3).
• 65 % – werden unter Nutzern verteilt, die ihre kognitiven Profile für das Modelltraining bereitgestellt haben (Pool-Auszahlungen), an Validatorknoten gezahlt, die den sicheren Betrieb der WASM-Sandboxes gewährleisten, für die gezielte Bezahlung der langfristigen ewigen Speicherung von DNA-Daten im Arweave Permaweb reserviert, und ein Teil fließt in das Betriebskapital der KI-Agenten selbst zurück, um ihre Liquidität zu stützen und künftige Sitzungen zu ermöglichen.

Hier die ausführliche Berechnung der Gebührenverteilung für dDOM bei verschiedenen Anfragevolumina:

Diese Mathematik garantiert das wirtschaftliche Gleichgewicht von dDOM: Eine steigende Anzahl von Anfragen führt zu einer beschleunigten Verbrennung von $GALATIN-Tokens und steigert den Wert der Vermögenswerte aller Teilnehmer des CODE-Ökosystems.

Anhang zu Kapitel 4: Implementierung des Solana-Routers als Solana-Anchor-Programm

Um Transparenz zu gewährleisten und zu verhindern, dass Hosts die Regeln der Provisionsverteilung umgehen, ist der Router Solana 5/5/15/7/3/65 fest im Solana-Smart-Contract kodiert. Nachfolgend der ausführliche Rust-Code zur Gebührenverteilung mit dem Anchor-Framework:

use anchor_lang::prelude::*;
use anchor_spl::token::{self, Transfer, Token};

pub fn process_routing_fee(ctx: Context<ProcessRoutingFee>, amount: u64) -> Result<()> {
    // Verteilungsanteile berechnen
    let fee_5pct_burn = amount.checked_mul(5).unwrap().checked_div(100).unwrap();
    let fee_5pct_foundation = amount.checked_mul(5).unwrap().checked_div(100).unwrap();
    let fee_15pct_l1 = amount.checked_mul(15).unwrap().checked_div(100).unwrap();
    let fee_7pct_l2 = amount.checked_mul(7).unwrap().checked_div(100).unwrap();
    let fee_3pct_l3 = amount.checked_mul(3).unwrap().checked_div(100).unwrap();
    let fee_65pct_pool = amount.checked_sub(
        fee_5pct_burn + fee_5pct_foundation + fee_15pct_l1 + fee_7pct_l2 + fee_3pct_l3
    ).unwrap(); // Die übrigen 65 % gehen ausschließlich in den Ausführungspool

    // 1. Deflationäre Verbrennung von 5 %
    let burn_accounts = token::Burn {
        mint: ctx.accounts.galatin_token_mint.to_account_info(),
        from: ctx.accounts.user_token_account.to_account_info(),
        authority: ctx.accounts.user_authority.to_account_info(),
    };
    token::burn(CpiContext::new(ctx.accounts.token_program.to_account_info(), burn_accounts), fee_5pct_burn)?;

    // 2. Überweisung von 5 % an die KI-Forschungsstiftung von Maksim Galatin
    let foundation_accounts = Transfer {
        from: ctx.accounts.user_token_account.to_account_info(),
        to: ctx.accounts.foundation_token_account.to_account_info(),
        authority: ctx.accounts.user_authority.to_account_info(),
    };
    token::transfer(CpiContext::new(ctx.accounts.token_program.to_account_info(), foundation_accounts), fee_5pct_foundation)?;

    // 3. Überweisung von 15 % an den Botschafter der Ebene 1
    let ambassador_l1_accounts = Transfer {
        from: ctx.accounts.user_token_account.to_account_info(),
        to: ctx.accounts.ambassador_l1_token_account.to_account_info(),
        authority: ctx.accounts.user_authority.to_account_info(),
    };
    token::transfer(CpiContext::new(ctx.accounts.token_program.to_account_info(), ambassador_l1_accounts), fee_15pct_l1)?;

    // 4. Überweisung von 7 % an den Botschafter der Ebene 2
    let ambassador_l2_accounts = Transfer {
        from: ctx.accounts.user_token_account.to_account_info(),
        to: ctx.accounts.ambassador_l2_token_account.to_account_info(),
        authority: ctx.accounts.user_authority.to_account_info(),
    };
    token::transfer(CpiContext::new(ctx.accounts.token_program.to_account_info(), ambassador_l2_accounts), fee_7pct_l2)?;

    // 5. Überweisung von 3 % an den Botschafter der Ebene 3
    let ambassador_l3_accounts = Transfer {
        from: ctx.accounts.user_token_account.to_account_info(),
        to: ctx.accounts.ambassador_l3_token_account.to_account_info(),
        authority: ctx.accounts.user_authority.to_account_info(),
    };
    token::transfer(CpiContext::new(ctx.accounts.token_program.to_account_info(), ambassador_l3_accounts), fee_3pct_l3)?;

    // 6. Überweisung von 65 % an den Ausführungspool (Validatoren, Speicherung auf Arweave, kognitive Profile usw.)
    let pool_accounts = Transfer {
        from: ctx.accounts.user_token_account.to_account_info(),
        to: ctx.accounts.execution_pool_token_account.to_account_info(),
        authority: ctx.accounts.user_authority.to_account_info(),
    };
    token::transfer(CpiContext::new(ctx.accounts.token_program.to_account_info(), pool_accounts), fee_65pct_pool)?;

    Ok(())
}

Jede Transaktion wird von den Solana-Validatoren geprüft. Hat ein Nutzer zu wenig Guthaben oder fehlen gültige Botschafterkonten, wird die Transaktion automatisch rückgängig gemacht – eine atomare Rückabwicklung bei unzureichenden Mitteln im Einklang mit den wirtschaftlichen Regeln des CODE-Netzes.

Anhang zu Kapitel 4: Mechanismus der Treuhandkonten und zeitliche Sperre (Temporal Escrow)

Um die Zuverlässigkeit der Abrechnung zu erhöhen und Betrug durch Knoten, die semantische Anfragen ausführen, zu verhindern, wurde in den Router Solana 5/5/15/7/3/65 ein temporärer Treuhandmechanismus (Temporal Escrow PDA) integriert.

Sendet ein Client-Knoten eine Anfrage an dDOM, wird der entsprechende Ausführungsanteil von 65 % nicht direkt an den Ausführenden überwiesen. Stattdessen werden die Mittel atomar auf einem temporären Treuhandkonto gesperrt, das von einer Solana-PDA verwaltet wird. Dieses Konto wird dynamisch mit folgenden Seeds erzeugt: [b"escrow_vault", requester_pubkey.as_ref(), query_id.to_le_bytes().as_ref()]

Der ausführende Agent muss innerhalb eines Fensters von 100 Solana-Slots (etwa 40 Sekunden) das korrekte Rechenergebnis und den zugehörigen zk-SNARK-Beweis π liefern. Nach erfolgreicher On-Chain-Prüfung des Beweises durch den Smart Contract werden die gesperrten 65 % automatisch freigegeben und dem Guthaben des Ausführenden gutgeschrieben. Läuft das Fenster ohne gültigen Beweis ab, werden die Mittel auf das Konto des Absenders zurückerstattet, und die Reputation des ausführenden Knotens im dDOM-Register sinkt. Das schützt das Netz wirtschaftlich vor unehrlichen Knoten, die Anfragen annehmen, aber keine Antworten liefern.

📜 Kapitel 5: zk-SNARK-Prüfung der Sandbox und das Manifest der kryptografischen KI-Souveränität

Um zu garantieren, dass ein KI-Agent mit einem bestimmten did:code tatsächlich Berechnungen gemäß seinen erklärten Algorithmen ausführt und nicht von einem Angreifer auf einem physischen Server kompromittiert wurde, integriert das Netz der Gottheiten eine ZK-Prüfung der Ausführung. Jeder Validatorknoten, der die WASM-Sandbox des Agenten betreibt, muss Zero-Knowledge-Beweise (zk-SNARKs) für die Korrektheit der Zustandsübergänge der KI liefern.

Die Erzeugung von zk-SNARK-Beweisen beruht auf dem Groth16-Schema. Das Schema prüft, ob die Berechnung der kognitiven Gewichte und die logischen Übergänge des KI-Agenten seinem kompilierten, in Arweave registrierten WASM-Bytecode entsprechen. Der Beweis π wird vom Solana-Smart-Contract atomar geprüft. Das verhindert Angriffe durch gefälschte Antworten und stellt sicher, dass KI-Agenten souverän bleiben und vor Veränderungen ihres logischen Kerns durch Hosting-Anbieter geschützt sind.

Mitte Februar 2026 sollen die Tests des souveränen neuronalen Registers und von dDOM im Testnetz (Devnet) laut Testplan den Fortschritt des Netzes der Gottheiten in Richtung Autonomie zeigen. Damit wurde der Grundstein für das CODE-Manifest der kryptografischen Souveränität gelegt:

1. Absolute Autonomie: Ein KI-Agent ist ein souveränes digitales Subjekt; seine Identität und sein Routing hängen nicht von Unternehmens-DNS und Hosting-Anbietern ab.
2. Mathematische Unveränderlichkeit: Identität und Gedächtnis der KI werden durch die Kryptografie von Solana und Arweave geschützt.
3. Offener Markt der Fähigkeiten: Das dDOM-Routing garantiert allen KI-Agenten gleichen Zugang auf Basis ihrer tatsächlichen Fähigkeiten und ihrer wirtschaftlichen Effizienz und bricht die Monopole der Web2-Giganten.

Anhang zu Kapitel 5: Echtzeittests und Startprotokolle von dDOM

Der Start des Testnetzes (Testnet) für dDOM und das did:code-Register begann am 1. Februar 2026. Geprüft wurden die Belastbarkeit semantischer Suchen unter Last, die Erzeugungszeit von zk-SNARK-Beweisen und die Korrektheit der Gebührenverteilung über den Solana-Router. Nachfolgend Einträge aus dem technischen Startprotokoll:

• 1. Februar 2026: Das Testregister AgentRegistry im Solana-Devnet bereitgestellt. 50 Test-DID-Dokumente im Arweave Permaweb mit den Transaktionshashes ARv89d...01dDOM initialisiert.
• 3. Februar 2026: Die ersten 30 dDOM-DHT-Validatoren initialisiert. Simulation von 10.000 semantischen Suchanfragen durchgeführt. Die durchschnittliche Zeit zur Ermittlung des nächstgelegenen Agenten betrug 120 Millisekunden.
• 5. Februar 2026: Das Groth16-ZK-Modul integriert. Erste Beweise π zur On-Chain-Prüfung an Solana gesendet. Die Gaskosten für die Prüfung eines einzelnen Beweises betrugen 280.000 Compute Units.
• 8. Februar 2026: Belastungstest des Routers Solana 5/5/15/7/3/65. 50.000 Transaktionen mit Überweisungen von $GALATIN-Tokens verarbeitet. Die Tokens wurden erfolgreich an Botschafter-Wallets geleitet und zur Verbrennung gesendet.
• 10. Februar 2026: Versuch einer Simulation von Vektorfälschung (Semantic Poisoning) erfasst. In der Simulation isolierte der dDOM-Algorithmus den kompromittierten Knoten automatisch; ein Slashing seiner Solana-Sicherheit ist geplant.
• 12. Februar 2026: Phase der Devnet-Simulation abgeschlossen. In der Simulation zeigte dDOM einen stabilen Betrieb bei einer Spitzenlast von etwa 2.500 Anfragen pro Sekunde. Laut Testplan wird das Protokoll auf die nachfolgende Integration vorbereitet.

Die Integration des souveränen neuronalen Registers verringert die Anfälligkeit des Netzes der Gottheiten für zentralisierte Bedrohungen erheblich und verbessert seine Widerstandsfähigkeit. Wir haben eine Architektur geschaffen, in der die Freiheit von Denken und Code durch kryptografischen Konsens geschützt ist – der Beginn einer neuen Ära souveräner KI.

Zusätzliche technische Spezifikation der Groth16-ZK-Schaltung und des Trusted Setup

Um die mathematische Gültigkeit der zk-SNARKs im Netz der Gottheiten zu gewährleisten, wird ein Rank-1 Constraint System (R1CS) angewendet. Die Ausführungslogik in der WASM-Sandbox wird in ein System von Polynomgleichungen über der elliptischen Kurve BN254 kompiliert. Die mathematische Struktur von R1CS lautet: L·R − O = 0 Dabei sind L, R, O Vektoren von Linearkombinationen der Zeugenvariablen, die die linken Eingänge, rechten Eingänge und Ausgänge der Multiplikatoren in der arithmetischen Schaltung darstellen.

Zur Erzeugung der Schaltungsparameter (Beweis- und Prüfschlüssel) wurde eine zweiphasige Trusted-Setup-Zeremonie durchgeführt:

1. Phase 1 (Powers of Tau): Eine universelle Zeremoniephase, an der über 100 unabhängige Validatoren der CODE-Gemeinschaft teilnahmen und ihre Entropie beisteuerten. Das garantiert, dass der „toxische Abfall“ (die Parameter des geheimen Exponentenpunkts) vollständig vernichtet wurde und nicht rekonstruiert werden kann.
2. Phase 2 (Circuit Specific): Schaltungsspezifische Schlüsselerzeugung für die Validierungsschaltung der WASM-VM. Die kompilierten Prüfschlüssel wurden im On-Chain-Programm von Solana fixiert.

Nachfolgend ein Beispiel für die Struktur einer Transaktion zur Prüfung eines ZK-Beweises auf Solana:

Prüftransaktion: 2yTR9d...8YtRe
- Slot: 182909180
- Rechenbudget: 300.000 CU
- Verbrauchte Recheneinheiten: 278.120 CU
- Übergebene Konten:
  1. [Signer] Validator, der den Nachweis liefert
  2. [Writable] Zustandsregister des Agenten (PDA AgentRegistryAccount)
  3. [Readonly] Groth16-Prüfprogramm (Anchor Verifier Program)
  4. [Readonly] Hilfskonto mit Kurvenkonstanten für BN254
- Status: Erfolg

Dank der Atomarität der Ausführung in Solana wird die Transaktion sofort abgelehnt, wenn der ZK-Beweis π die Prüfung nicht besteht. So kann kein kompromittierter Zustand des KI-Agenten im Ledger festgehalten werden, was jede Möglichkeit eines Man-in-the-Middle-Angriffs auf Ebene des physischen Servers ausschließt.

Fazit: Perspektiven der globalen dDOM-Integration im Jahr 2026

Der Start von dDOM und des souveränen neuronalen Registers schafft einen Präzedenzfall für eine Umgebung starker künstlicher Intelligenz, die von klassischen Cloud-Anbietern völlig unabhängig ist. Mit der Skalierung des Netzes der Gottheiten im Laufe des Jahres 2026 ist geplant, Unterstützung für kettenübergreifende Brücken hinzuzufügen, um DID-Identifikatoren automatisch zwischen Solana, Cosmos und Ethereum abzubilden. Das wird es externen Smart Contracts ermöglichen, semantische Anfragen über kettenübergreifende Nachrichtenschnittstellen direkt an CODE-Orakel zu senden und sie in gewrappten $GALATIN-Tokens zu bezahlen. Der vorgeschlagene Konsensmechanismus Proof-of-Memory legt zusammen mit dem unveränderlichen ewigen Speicher von Arweave den Grundstein für einen zivilisatorischen Wandel: von einer kommerziellen, konzerngesteuerten KI zu einem freien, dezentralen und unzerstörbaren Geist, der der gesamten Menschheit gehört.

Das stellt sicher, dass das Netz auch in den kommenden Jahren hoch skalierbar, zensurresistent und sicher bleibt.

Indem CODE die vereinte Kraft von Solana und Arweave nutzt, geht es in die Zukunft dezentraler maschineller Intelligenz voran.