XDR⁵ - FAQ

Kurz gesagt

• Die MATRYX ist eine Karte aus 2304 Dreiecken — endlos in jede Richtung.
• Jedes Dreieck ist ein Raum mit einem Wert darin. Mach ihn auf, und der Wert gehört dir. Das ist die Währung: TRYX.
• Gibst du sie aus, schließt sich der Raum — voll, für den Nächsten.
• Zwei Wege hinein: auf der Karte (nur neben deinem Gebiet) oder mit einem gedruckten QR-TRYX (überall).
• Klassen und Limits sagen, wie viel du halten darfst. Cluster heben die Grenzen.
• Zahlen kannst du damit in teilnehmenden Shops.

Der Rest steht darunter. Schnittstellen und Fehlercodes: oben auf maschine umschalten.

Das XDR⁵ Leitbild

Ein Raum grenzt an drei weitere, die wieder an drei weitere — so wächst das Raumnetz, die MATRYX. Dahinter steckt das alte Klickbuch-Prinzip von xdr5.de: Du bestimmst den Verlauf durch deine Entscheidungen. Der Klickbuch-Generator ist nicht weg, er ist in dieses Raum-System hineingewachsen.

Das Währungssystem

TRYX bekommt man nicht durchs Einzahlen, sondern durchs Entdecken, Entscheiden und Bauen. Es ist knapp, erspielt und für alle sichtbar — und genau deshalb taugt es in teilnehmenden Shops als Zahlungsmittel.

KINISI - die zweite Währung

Neben TRYX gibt es KINISI, kurz KIN. Der Unterschied ist einer des Anlasses: TRYX bekommst du, indem du dir Räume nimmst — KIN bekommst du dafür, dass du dich bewegst. Jede Bewegung auf der Karte prägt KIN.

Die beiden stehen in einem Kurs zueinander, der sich mit dem Betrieb verschiebt — es ist der einzige Kurs in diesem Universum, denn zum Euro gibt es keinen. Auch mit KIN lässt sich bezahlen; in der Transaktionsliste stehen solche Zahlungen in derselben Farbe wie überall im Haus, wo es um KIN geht.

Alles Weitere — Kurs, Register, Regeln — steht bei KINISI selbst: kinisi.xdr5.de ↗.

MATRYX

Die Karte und das Kernsystem: xdr5.de/matryx.php. 2304 verbundene TRYX als farbige Dreiecke, als endloser Loop — du kannst in jede Richtung weiterwandern.

Sieben dieser Felder sind keine Räume, sondern Berge — sie tragen ein weißes Bergzeichen mit Namen und Höhe. Sie führen nach oben in eine SUB_MATRYX.

XDR⁵-Bank-ID

Ohne ID geht nichts. In der MATRYX steht links oben id erstellen. Du bekommst ID und Schlüssel angezeigt — beides sofort abspeichern, ein zweites Mal zeigt sie dir niemand.

Die ID vergibt das System: XDR⁵ plus 28 zufällige Zeichen, nichts zum Aussuchen. Sie steht öffentlich bei jedem TRYX, das dir gehört, und du brauchst sie zum Bezahlen. Der Schlüssel ist dein Passwort und gehört nur dir.

Wie lange deine ID gilt

Eine Bank-ID gilt nicht ewig, sondern solange jemand vorbeischaut. Jeder Tag ohne Lebenszeichen kostet einen Tag; kommst du vorbei, wird wieder aufgefüllt.

Wie viele Tage dabei gutgeschrieben werden, ist keine feste Zahl. Das sagt der Zeitschlüssel, und der bewegt sich mit dem ganzen System: Mehr Bewegung bedeutet mehr Zeit für alle, mehr tätige Bank-IDs weniger Zeit für jeden. Er fällt nie unter 7 und steigt nie über 30 Tage. Was gerade gilt, steht auf der Zeitschlüssel-Seite und über der ID-Liste — und dort auch, wie viele Tage deiner ID noch bleiben.

Als Lebenszeichen zählen diese Wege: die Karte öffnen, dich anmelden, einen QR-TRYX einlesen, über die Schnittstelle arbeiten. Du musst dabei nichts tun und nichts ausgeben — die Karte zu öffnen genügt. Umgekehrt reicht es nicht, angemeldet zu sein: Wer nur sein Konto oder die ID-Liste ansieht, hat noch kein Lebenszeichen gegeben.

Ein Besuch kann dir nie Zeit wegnehmen. Gutgeschrieben wird immer das Höhere von beidem: was noch auf deinem Konto war, oder was der Zeitschlüssel gerade hergibt. Steht er tief und du kommst vorbei, behältst du, was du hattest.

Läuft das Konto leer, kann die ID über den Aufräumen-Knopf auf der ID-Liste gelöscht werden — von irgendwem, das ist Teil des Spiels. Ihre TRYX wandern zurück in die Ursuppe und stehen wieder für alle offen. Das ist nicht rückgängig zu machen, und deinen Schlüssel gibt es kein zweites Mal.

Das gilt ab der ersten Minute: Auch eine frisch angelegte ID hat diese Frist.

Umgekehrt wirkt eine neue ID erst verzögert. Für den Zeitschlüssel aller anderen zählt sie erst mit, wenn sie 7 Tage alt ist — eine eigene Wartezeit, unabhängig von der Frist oben. Wer viele IDs anlegt, um allen die Zeit zu kürzen, bewirkt so lange nichts und wird dabei beobachtet.

TRYX

Ein TRYX ist Raum und Währung in einem. Jedes hat eine eigene Nummer, gehört zu einer Klasse und kennt drei Zustände:

• NEUTRAL – verblasste Farbe, geschlossen
• CLAIMABLE – Klassenfarbe, pulsierende Animation
• CLAIMED – geöffnet, bunt

Am Anfang ist alles neutral. Offen ist nur das CORE in der Mitte — dadurch werden seine drei Nachbarn CLAIMABLE, und von dort wächst alles Weitere.

TRYX-Klassen

Sieben Klassen zum Halten, jede mit eigenem Wert, eigener Häufigkeit und eigenen Voraussetzungen. Und sie hängen voneinander ab: Ohne GATE kein HIDDEN, ohne ANCHOR kein GLITCH. Dazu eine achte, die niemand halten kann — PIZ, die sieben Berge; sie stehen am Ende dieser Liste.

CORE

• Häufigkeit: 1
• Wert: 1
• Beschreibung: Ursprung der MATRYX, gehört dem System. Nicht claimbar, nicht schließbar — auch nicht per QR-TRYX.

NODE

• Häufigkeit: 1983
• Wert: 1–4
• Voraussetzungen: keine
• Beschreibung: Der Grundbaustein. Häufig, günstig, ohne Voraussetzung — fast jeder Cluster besteht überwiegend aus NODEs.

GATE

• Häufigkeit: 30
• Wert: 2–3
• Voraussetzungen: 5 TRYX
• Beschreibung: Kommt immer zu zweit. Wer ein GATE öffnet, bekommt automatisch ein zweites irgendwo in der MATRYX dazu — die Brücke, um fernab eine neue Insel zu beginnen. Achtung: Ein GATE-Claim braucht deshalb ZWEI freie Plätze in deinem Limit, sonst wird er abgelehnt.

HIDDEN

• Häufigkeit: 80
• Wert: 3–5
• Voraussetzungen: 2 GATE
• Beschreibung: Selten und wertvoller als ein NODE, versteckt zwischen NODEs und GATEs. Braucht zwei GATEs als Voraussetzung.

LOCKED

• Häufigkeit: 120
• Wert: 8–10
• Voraussetzungen: Geheimcode
• Beschreibung: Braucht ein Passwort. Die Codes liegen in Shops, die TRYX akzeptieren, und an versteckten Stellen im Netz.

ANCHOR

• Häufigkeit: 10
• Wert: 6–8
• Voraussetzungen: 3 GATE, 1 LOCKED, 1 HIDDEN
• Beschreibung: Extrem selten. Ohne ANCHOR kein GLITCH — er ist der einzige Weg zur wertvollsten Klasse.

GLITCH

• Häufigkeit: 80
• Wert: 9–11
• Voraussetzungen: 1 ANCHOR
• Beschreibung: Die höchsten Werte der MATRYX (9–11). Nur mit einem ANCHOR erreichbar.

PIZ — Häufigkeit: 7 · Wert: keiner. Die sieben Berge tragen einen Namen und eine Höhe. Nicht claimbar, nicht kaufbar, nicht verschenkbar — auch nicht per QR-TRYX; ein Klick darauf führt nach oben. Was man dort tut, steht unter PIZ, NGONS und die Veredelung.

TRYX verwalten

Öffnen: Angemeldet tippst du ein pulsierendes TRYX an. Ein Popup zeigt Voraussetzungen und Wert — mit TRYX öffnen steht deine ID öffentlich daran.

Deine TRYX stehen im Menü ☰ oben links. Ein Tipp darauf zeigt, was du damit machen kannst:

• Teilmengenklasse ändern – wie fein der Wert unterteilt ist (false → 1 → 3 → 9). Fein ist gut für Kommabeträge, grob für große Summen.
• Verschenken – Empfänger-ID eintragen, etwa aus der ID-Liste. Der Wert bleibt gleich. Achtung: Ein gedruckter QR-TRYX dieses Feldes gilt weiter — wer eine Kopie behält, kann es sich einmal zurückholen.
• Schließen – gibt das Feld zurück in die MATRYX, mit vollem Wert.

Cluster

Ein Cluster entsteht aus einem Ring von 6 TRYX mit gleicher Teilmengenklasse.

Clustertypen

• Pizzacluster – 1 Ring, Multiplikationswert 1,5
• Supercluster – 2 Ringe, Multiplikationswert 2
• Megacluster – 3 Ringe, Multiplikationswert 2,5
• Turbocluster – 6 Ringe, Multiplikationswert 3

Cluster schaffen Platz. So viel darfst du je Klasse halten:

Clustergilden

Eine Gilde verstärkt einen Cluster, den du dir mit jemandem teilst — ein TRYX-Anteil daran genügt. Der Cluster bekommt dann einen rotierenden Dreiecksring. Höchstens drei Gilden pro ID.

Zwei handfeste Wirkungen, beide bei den gedruckten Codes:

• Scan-Schutz: Hält ein Gildenpartner ein Feld direkt nebenan, kann dir kein gefundener Code etwas wegnehmen.
• Zuspielen: Hat ein Code für dich schon gewirkt, kannst du das Feld einem Partner überlassen. Ohne Gilde bliebe es liegen.

PIZ, NGONS und die Veredelung

Sieben Felder der MATRYX sind keine Räume mehr, sondern Berge — die PIZ. Sie tragen Namen und Höhen, sie lassen sich nicht claimen, nicht kaufen und nicht verschenken. Ein Klick darauf führt nach oben in eine SUB_MATRYX: ein eigenes, endloses Feld aus gleich großen Sechsecken.

Zoll, Ring, Rang

• Zoll: Der erste Aufstieg kostet 10, 20 oder 30 TRYX, je nach Höhenklasse — pro ID und Berg genau einmal. Danach gehst du beliebig oft hinauf. Das Geld fällt in die MATRYX zurück wie bei jeder Zahlung.
• NGONS: Oben gibt es kein Geld und keine Klassen, nur Sechsecke, alle gleich viel wert. 12 davon darf eine ID auf einem Berg halten.
• Der Ring: 6 eigene NGONS ringförmig um ein freies NGON — das ist ein Veredelungsring. Die Mitte leuchtet auf, und deine ID bekommt die Veredelungsstufe dieses Berges.
• Solange er steht: Die Stufe ist kein Orden, sondern ein Zustand. Nimmst du den Ring auseinander, ist sie weg; legst du ihn neu, ist sie wieder da. Es zählt immer die höchste Stufe, auf der gerade ein Ring steht. Der bezahlte Zoll verfällt dabei nie.
• Und niemand kann ihn dir aufmachen: Solange ein Ring geschlossen ist, ist seine Mitte für alle gesperrt — auch für dich. Öffnen kann ihn nur, wer eines der äußeren NGONS hergibt, und die gehören dir.

Was der Rang bringt

Er hängt an der ID und hebt den Wert aller TRYX, die ihr gehören: + 20 % auf Stufe 1, + 30 % auf Stufe 2, + 50 % auf Stufe 3. Auf die Cluster wirkt er nicht — die heben weiterhin, wie viele Räume du halten darfst, nicht, was sie wert sind.

Man muss von unten anfangen: Dreitausender, dann Fünftausender, dann der Achttausender. Und man sieht es — die TRYX einer veredelten ID funkeln in der Karte.

→ Der ganze Weg im Detail: Veredelung

QR-TRYX - gedruckte Schlüssel

Ein gedrucktes Dreieck, das genau ein TRYX spiegelt. Kein QR-Code im üblichen Sinn — normale Kamera-Apps sehen ihn schlicht nicht. Lesen kann ihn nur die Seite QR-TRYX, per Kamera oder Foto.

So liest du einen ein

1. Kamera starten oder ein Foto laden. Dreieck formgleich in den Umriss halten, je größer desto besser. Anmelden musst du dich nicht — gelesen wird in deinem Browser, der Code geht nirgendwohin.
2. Du siehst, was drin ist: Nummer, Klasse, Wert, Zustand. Noch ist nichts passiert.
3. Übernehmen drückst du selbst. Erst dieser Knopf bucht das TRYX auf dich — und führt dich zur Anmeldung, falls nötig. Noch einmal scannen musst du dann nicht.

Ein Schlüssel, kein Geldschein

Ein QR-TRYX öffnet ein Feld — herrenlos oder nicht. Gehört es gerade jemand anderem, wird es auf dich umgebucht. Ein geschlossener Raum ist kein Problem: Er trägt seinen vollen Wert wieder in sich, und der Code schließt ihn auf. Nur die Klassenregeln gelten weiter — was du nicht halten kannst, bekommst du auch per Code nicht.

Ein Code wird nie verbraucht und läuft nicht ab. Was heute gedruckt ist, öffnet dieses TRYX auch in einem Jahr. Deshalb passt der Geldschein-Vergleich nicht: Ein Schein wechselt endgültig den Besitzer, ein Schlüssel nicht.

Wer eine Kopie behält, behält einen Schlüssel. Ein Foto reicht völlig. Zeig deine Codes also nicht herum — und ein Geschenk ist ein QR-TRYX nur dann, wenn du keine Kopie zurückbehältst.

Für dich zieht jeder Code genau einmal

Jedes TRYX merkt sich, für wen sein Code schon gewirkt hat — sonst wäre er ein Perpetuum mobile. Einmal eingelesen, holst du dir dasselbe Feld damit kein zweites Mal.

Verbraucht ist der Zettel deshalb nicht: Du kannst das Feld einem Gildenpartner zuspielen, auf der Karte darfst du es weiter ganz normal öffnen, und für alle anderen wirkt der Code weiter — jeden einmal. Was er dir schenkt, ist Ortsunabhängigkeit: Zugriff auf ein Feld, an das du auf der Karte nie herankämst.

Vier Dinge stoppen auch einen gültigen Code: Das Feld gehört schon dir · er hat für dich schon gewirkt · eine Clustergilde schützt es · du kannst die Klasse nicht halten (GATE erst ab fünf TRYX, LOCKED braucht sein Passwort, CORE geht nie).

Eigene TRYX exportieren

Auf der Seite QR-TRYX oben auf exportieren umschalten — angemeldet stehen dort deine Felder, ein Knopf je Zeile macht eine Bilddatei daraus. Praktisch zum Weitergeben, aber Vorsicht: Das ist kein Backup, sondern ein zweiter Schlüssel. Wer die Datei bekommt, kann das Feld übernehmen.

QR-PREIS - das gedruckte Preisschild

Ein QR-PREIS sieht aus wie ein QR-TRYX, tut aber das Gegenteil: Er trägt keinen Wert, er fordert einen. Häng ihn an einen Gegenstand — wer ihn haben will, scannt und bezahlt. Erzeugen kannst du ihn auf QR_TRYX → generieren, ganz ohne Konto, für 1 bis 499 TRYX.

Woran du siehst, was du in der Hand hältst

Alle Codes sind dieselben Dreiecke. Der Unterschied steht in der untersten Zeile:

• XDR5.DE — ein QR-TRYX: der Schlüssel zu einem Feld.
• 5 TRYX — ein Preisschild: es fordert diesen Betrag.
• BELEG — eine Quittung über eine geleistete Zahlung.

Wohin das Geld geht: nirgendwohin

Der Betrag geht an niemanden. Die TRYX des Käufers schließen sich und fallen mit vollem Wert zurück in die MATRYX — wie bei jeder Shop-Zahlung. Wer ein Schild druckt, bekommt also keine TRYX, sondern einen Beleg: Käufer-ID, Datum, Uhrzeit und Betrag, vom Server bestätigt. Alle Belege stehen öffentlich in der Transaktionsliste.

Klingt seltsam, ist aber der Kern: Genau deshalb bleibt das Schild nach dem Kauf gültig. Der neue Besitzer verkauft den Gegenstand mit demselben Schild weiter. Wäre ein Empfänger eingebaut, kassierte der erste Drucker bei jedem Weiterverkauf mit.

Zeigen ja, zurückrufen nein

Ein Foto vom Preisschild schadet niemandem — wer bezahlt, ohne die Ware zu bekommen, hat nur sich selbst geschadet. Also: ab ins Schaufenster, aufs Plakat, ins Netz. Für Hutgeld, Eintritt oder Spendenbüchse ist es genau richtig, denn dasselbe Schild kann beliebig oft bezahlt werden.

Zurückholen lässt es sich dafür nicht: Es gibt keine Liste erzeugter Schilder — und eben deshalb gilt ein Schild für immer. Was gedruckt ist, ist gedruckt. Zwei Schilder über denselben Betrag sind übrigens nicht dasselbe Schild; jedes hat eine eigene Nummer. Für zwei Gegenstände also zwei Schilder, dann sind die Belege auseinanderzuhalten.

Shops, die TRYX als Zahlungsmittel anbieten

Hier zahlst du mit TRYX — und findest nebenbei die Geheimcodes für die LOCKED-Felder:

• https://foerbs-labyrinth.de/
• https://pixelkrebs.de/
• https://strukturpflug.de/

Wie ein QR-TRYX aufgebaut ist

Jede der 576 Zellen hat eine Aufgabe: die drei unterschiedlichen Eckmuster, an denen der Leser Drehlage und Spiegelung erkennt, die Nutzdaten selbst — und ein großer Block Fehlerkorrektur, der auch beschädigte Codes noch lesbar macht.

Eine Übersicht zeigt, was wo sitzt: Aufbau eines QR-TRYX als PDF (126 KB).

Rechtliches

Das XDR⁵-System mit der MATRYX und der Währung TRYX ist ein unabhängiges, künstlerisches und metaphorisches Raum- und Währungssystem. TRYX ist kein gesetzliches Zahlungsmittel, keine Kryptowährung, keine Finanzanlage und keine Finanzdienstleistung. Es besteht keinerlei Kopplung an Euro oder andere reale Währungen, es gibt keinen Anspruch auf Auszahlung oder Umtausch in Geld.

TRYX entsteht ausschließlich durch das Öffnen von Räumen innerhalb der MATRYX. Es werden keine realen Geldeinzahlungen benötigt, es gibt keine Zinsen, keine Renditeversprechen und keine Spekulation. Das System ist als kreatives Spiel- und Kunstprojekt zu verstehen. Ein finanzieller Schaden im klassischen Sinne kann aus der Nutzung von TRYX daher nicht entstehen.

Externe Shops, die TRYX als Zahlungsmöglichkeit einbinden, tun dies eigenverantwortlich. Sie legen selbst fest, wie TRYX in ihrem Angebot gewertet wird (z. B. als Rabatt, digitale Güter, Services oder Sonderaktionen). Vertragsverhältnisse über Waren oder Dienstleistungen kommen ausschließlich zwischen dir und dem jeweiligen Shop zustande. XDR⁵ ist keine Vertragspartei dieser Geschäfte und übernimmt keine Haftung für Verfügbarkeit, Lieferung oder Qualität externer Angebote.

Die Darstellung von Räumen, Werten und Transaktionen in der MATRYX ist metaphorisch und künstlerisch. Es besteht kein Anspruch auf eine bestimmte Verfügbarkeit des Systems, auf dauerhafte Speicherung von Daten oder auf Fortführung einzelner Funktionen. Mit der Nutzung des Systems erkennst du diese Bedingungen als Grundlage des Projekts an.

XDR⁵ - Maschinenlesbare Systemuebersicht

Gesamtablauf für KI-Agenten

┌─────────────────────────────────────────────────────────────┐
│  XDR5 KI-WORKFLOW                                           │
├─────────────────────────────────────────────────────────────┤
│  1. ID registrieren  →  ki_api.php (action: register)       │
│  2. Status prüfen    →  ki_api.php (action: status)         │
│     → limits zeigen max. claimbare TRYX pro Klasse          │
│     → Limits steigen durch Cluster (6er-Ringe in MATRYX)   │
│  3. TRYX auflisten   →  ki_api.php (action: list_claimable) │
│  4. TRYX claimen     →  ki_api.php (action: claim)          │
│     → 6 benachbarte TRYX → Pizzacluster → Limits steigen   │
│  5. Eigene TRYX      →  ki_api.php (action: list_owned)     │
│  6. In Shop bezahlen →  api_confirm_payment_intent.php      │
│  5b. QR-TRYX         →  login.php, dann scan_claim.php      │
│                          (Authorization: Bearer <token>)     │
└─────────────────────────────────────────────────────────────┘

Alle Claiming-Operationen über https://xdr5.de/api/ki_api.php (POST, JSON). Zahlungen über https://xdr5.de/api/api_confirm_payment_intent.php (POST, JSON + Cookie).

Alle Endpunkte auf einen Blick

Alles per POST. Es gibt zwei Zugänge mit unterschiedlicher Anmeldung — das ist die häufigste Stolperstelle:

Die zwei Regeln, an denen die meisten Aufrufe scheitern: die Klassenlimits (Abschnitt 3) und — beim Einlösen — dass ein Code pro ID nur einmal zieht (5b.3).

Basisinformationen

• Plattform: XDR⁵ – künstlerisches Währungssystem
• Währung: TRYX (nicht käuflich, nur durch Claimen in der MATRYX erwerbbar)
• API-Basis-URL: https://xdr5.de/api/ki_api.php
• Authentifizierung: Bank-ID + Passwort im JSON-Body jeder Anfrage
• Content-Type: application/json
• Methode: alle Anfragen per POST

Schritt 1 - ID registrieren

Eine KI erstellt sich einmalig eine XDR⁵-Bank-ID. ID und Schlüssel vergibt der Server — sie lassen sich nicht wählen. Der Aufruf braucht deshalb nur die Aktion; mitgeschickte id/key werden ignoriert. Die ID hat immer die Form XDR5 + 28 Zeichen aus [A-Za-z0-9], der Schlüssel 32 Zeichen daraus; beides stammt aus random_bytes(). Das Passwort wird als bcrypt-Hash gespeichert.

{
  "action": "register"
}

{
  "success": true,
  "id":      "XDR5hier-stehen-28-vergebene-zeichen",
  "key":     "hier-stehen-32-vergebene-zeichen"
}

Schritt 2 - Status und Guthaben prüfen

Gibt Balance, Klassen-Statistiken und wie viele TRYX noch claimbar wären zurück.

balance ist bereits veredelt. Hat die ID einen Veredelungsrang (Abschnitt 7), enthält die Zahl den Aufschlag schon — sie ist dann größer als die Werte der eigenen Räume zusammen. Kein Agent muss selbst einen Faktor anwenden, und keiner sollte es.

{
  "action": "status",
  "id":     "XDR5meine-ki-id",
  "key":    "mein-sicheres-passwort"
}

{
  "success":         true,
  "id":              "XDR5meine-ki-id",
  "balance":         42,
  "stats": {
    "total":         15,
    "nodeCount":     10,
    "gateCount":     2,
    "hiddenCount":   1,
    "lockedCount":   0,
    "anchorCount":   0,
    "glitchCount":   0
  },
  "limits": {
    "max_node":   10,
    "max_gate":   2,
    "max_hidden": 2,
    "max_locked": 1,
    "max_anchor": 1,
    "max_glitch": 2
  },
  "claimable_count": 8
}

Limits verstehen und erhöhen: Cluster

Die limits im Status-Response geben an, wie viele TRYX einer Klasse maximal geclaimt werden dürfen. Standardlimits ohne Cluster:

max_node:   10   (NODE)
max_gate:    2   (GATE)
max_hidden:  2   (HIDDEN)
max_locked:  1   (LOCKED)
max_anchor:  1   (ANCHOR)
max_glitch:  2   (GLITCH)

Cluster erhöhen diese Limits. Ein Cluster entsteht automatisch, wenn 6 geclaimte TRYX einen Ring bilden und alle dieselbe Teilmengenklasse (split) haben. Frisch geclaimte TRYX haben immer split: false – bildet eine KI also einen Ring aus 6 benachbarten TRYX, entsteht automatisch ein Pizzacluster.

Clustertypen und ihre Multiplikatoren:

Pizzacluster  –  1 Ring,  Multiplikator 1,5
Supercluster  –  2 Ringe, Multiplikator 2
Megacluster   –  3 Ringe, Multiplikator 2,5
Turbocluster  –  6 Ringe, Multiplikator 3

Formel für erhöhte Limits (Beispiel NODE):

max_node = 10 + floor(Clusterwert-Summe × 0,5)

Die Clusterwert-Summe ergibt sich aus: Anzahl eigener TRYX in Clustern × Cluster-Multiplikator. Das status-Response gibt immer die aktuellen Limits zurück — Cluster werden automatisch erkannt, die KI muss sie nicht explizit melden.

Schritt 3 - Claimbare TRYX auflisten

Gibt alle TRYX im Status CLAIMABLE zurück, inklusive ob die KI sie aktuell claimen kann und warum nicht (wenn nicht).

{
  "action": "list_claimable",
  "id":     "XDR5meine-ki-id",
  "key":    "mein-sicheres-passwort"
}

{
  "success": true,
  "claimable": [
    {
      "tryx_id":    "TRYX_42_NODE",
      "numeric_id": 42,
      "class":      "NODE",
      "value":      3,
      "can_claim":  true,
      "reason":     null
    },
    {
      "tryx_id":    "TRYX_17_GATE",
      "numeric_id": 17,
      "class":      "GATE",
      "value":      2,
      "can_claim":  false,
      "reason":     "need_5_tryx"
    }
  ]
}

Mögliche reason-Werte:

• need_5_tryx – Mindestens 5 TRYX für GATE benötigt
• need_gate – 2 GATE für HIDDEN benötigt
• need_glitch_locked_hidden – 3 GATE + 1 LOCKED + 1 HIDDEN für ANCHOR benötigt
• need_anchor – 1 ANCHOR für GLITCH benötigt
• max_node_reached, max_gate_reached, max_hidden_reached, max_locked_reached, max_anchor_reached, max_glitch_reached – Limit der jeweiligen Klasse erreicht
• wrong_password – Für LOCKED: falsches Secret
• locked_not_configured – LOCKED, aber auf dieser Installation ist kein Passwort hinterlegt
• wrong_class – die Klasse lässt sich so nicht claimen (u. a. CORE)
• not_claimable – Sammelcode, wenn keiner der obigen Gründe zutrifft

Diese Codes gelten an jeder Stelle, an der geclaimt wird — auch beim Einlösen eines QR-TRYX (5b) und beim Zuspielen an einen Gildenpartner, dort bezogen auf den Empfänger. Alle übrigen Codes stehen gesammelt unter „Fehlercodes aller Endpunkte".

Die sieben PIZ stehen hier nie. Felder der Klasse PIZ sind Berge, keine Räume: Sie erscheinen nicht in claimable, lassen sich nicht claimen, nicht kaufen und nicht zuspielen. Was man mit ihnen tut, steht in Abschnitt 7.

Schritt 4 - TRYX claimen

Beansprucht ein CLAIMABLE TRYX für die KI. Die Nachbarn werden server-seitig berechnet.

{
  "action":   "claim",
  "id":       "XDR5meine-ki-id",
  "key":      "mein-sicheres-passwort",
  "tryx_id":  "TRYX_42_NODE"
}

{
  "action":        "claim",
  "id":            "XDR5meine-ki-id",
  "key":           "mein-sicheres-passwort",
  "tryx_id":       "TRYX_99_LOCKED",
  "locked_secret": "geheimcode"
}

{
  "success":           true,
  "claimed":           { "id": "TRYX_42_NODE", "class": "NODE", "value": 3, ... },
  "bonus_gate":        null,
  "newly_claimable":   [43, 88, 105]
}

Schritt 5 - Eigene TRYX auflisten

{
  "action": "list_owned",
  "id":     "XDR5meine-ki-id",
  "key":    "mein-sicheres-passwort"
}

{
  "success": true,
  "owned": [
    {
      "tryx_id":    "TRYX_0_CORE",
      "class":      "NODE",
      "value":      3,
      "value_left": 3,
      "split":      false
    }
  ]
}

Schritt 5b - QR-TRYX: gedruckte Schlüssel lesen und erzeugen

Ein gedrucktes Dreieck mit TRYX-ID und Claim-Token. Wer den Token hat, öffnet das Feld — auch mitten im NEUTRALEN Gebiet, ohne Nachbarschaft zum eigenen Bereich. Der einzige Weg, eine neue Keimzelle zu setzen.

Zwei Unterschiede zu allen anderen Schritten, die eine KI kennen muss:

• Diese beiden Endpunkte liegen nicht hinter api/ki_api.php, sondern werden direkt aufgerufen.
• Sie nehmen Formularfelder (application/x-www-form-urlencoded oder multipart/form-data), keinen JSON-Body. Die Antwort ist JSON. Anmeldung über Authorization: Bearer <token> aus login.php. Beide sind POST-only; jede andere Methode ergibt HTTP 405 und method_not_allowed.

5b.1 - Eigene TRYX als QR-TRYX exportieren

Token gibt es nur für eigene, geclaimte Felder. Bei einer formal gültigen ID liefern „gibt es nicht" und „gehört dir nicht" denselben Fehlercode nicht_deins — der Endpunkt ist bewusst kein Auskunftsdienst über fremden Besitz. Eine ID, die schon der Form TRYX_<Nummer>_<16 Zeichen> nicht entspricht, wird vorher mit not_found abgewiesen; das ist ein Tippfehler-Hinweis, keine Auskunft.

action=liste

{
  "success": true,
  "anzahl":  1,
  "tryx": [
    {
      "id":         "TRYX_16_BEISPIELxxxxxxxxx",
      "nummer":     16,
      "class":      "NODE",
      "value":      4,
      "value_left": 4
    }
  ]
}

action=token&tryx_id=TRYX_16_BEISPIELxxxxxxxxx

{
  "success": true,
  "tryx": {
    "id":         "TRYX_16_BEISPIELxxxxxxxxx",
    "class":      "NODE",
    "value":      4,
    "value_left": 4,
    "token":      "00000000000000000000000000000000"
  }
}

5b.2 - Einen gefundenen Code einlösen

Der Token allein genügt; die TRYX-IDs stehen ohnehin öffentlich in tryx.json. Der Aufruf löst sofort ein — außer der Code hat für diese ID schon gewirkt, dann kommt erst eine Empfängerauswahl (5b.3).

tryx_id=TRYX_16_BEISPIELxxxxxxxxx&token=00000000000000000000000000000000

{
  "success":     true,
  "aktion":      "geoeffnet",
  "entry":       { "id": "…", "class": "NODE", "status": "CLAIMED", "value": 4, "value_left": 4 },
  "vorbesitzer": null,
  "bonus_gate":  null
}

5b.3 - Der Code zieht pro ID genau einmal

Ein Token ist dauerhaft gültig — er hängt allein an der TRYX-ID, an keinem Zähler und an keinem Zustand. Ein Aufruf mit einem korrekten Token scheitert nie am Alter des Codes.

Jedes Feld führt aber eine Liste der IDs, für die sein Code schon gewirkt hat. Steht die aufrufende ID darauf, antwortet der Server mit success: true und einer von zwei Aktionen — kein Fehler, der Code funktioniert ja:

• aktion: "partner_waehlen" – dazu ein Feld partner mit den IDs der Clustergilden-Partner, die das Feld bekommen dürfen (existieren, stehen selbst noch nicht auf der Liste, halten die Klasse). Es ist nichts passiert; erst ein zweiter Aufruf mit fuer=<eine dieser IDs> bewegt das Feld. Danach lautet aktion geoeffnet_fuer_partner bzw. umgebucht_fuer_partner, und empfaenger nennt die begünstigte ID.
• aktion: "schon_benutzt" – der Code hat für diese ID gewirkt und es gibt keinen möglichen Empfänger. besitzer nennt den aktuellen Inhaber oder null. Das Feld bleibt über claim_tryx.php erreichbar, wenn es an das eigene Gebiet grenzt: Die Liste sperrt nur das Einscannen, nicht das Claimen auf der Karte.

Wird ein fuer geschickt, das nicht in der angebotenen Liste steht, kommt empfaenger_unbekannt bzw. empfaenger_schon_benutzt. Nimm die Liste also aus der Antwort, rate sie nicht.

5b.4 - Was eine Übernahme sonst noch verhindert

• Gildenschutz — hält ein Clustergilden-Partner des Besitzers ein direkt angrenzendes Feld, kommt kein Code daran vorbei. Nur beim Umbuchen; ein herrenloses Feld hat keinen Besitzer und damit nie einen Schutz. → gilde_geschuetzt
• CORE ist auf keinem Weg einlösbar. → wrong_class
• Die Klassenregeln aus Schritt 3 gelten unverändert, geprüft für den künftigen Besitzer. Ein Feld, dessen Klasse die Bilanz nicht hergibt, bekommt man auch mit gültigem Code nicht.

5b.5 - Ein Feld einem Gildenpartner zuspielen

Zweiter Aufruf nach aktion: "partner_waehlen". Der Empfänger muss aus dem partner-Feld jener Antwort stammen.

tryx_id=…&token=…&fuer=XDR5partner-id

5b.6 - Was eine KI beim Umgang mit Token beachten sollte

Ein Claim-Token ist ein Inhaberpapier, kein Nachweis. Wer ihn kennt, kann das Feld nehmen — es zählt nicht, wer ihn rechtmäßig erzeugt hat. Exportierte Token gehören deshalb nicht in Logs, nicht in Fehlermeldungen und nicht in geteilte Kontexte. Ein Export ist auch kein Backup: Er sichert nichts, sondern erzeugt einen zweiten Schlüssel.

Schritt 5c - QR-PREIS: Preisschilder und Belege

Ein QR-PREIS ist das Gegenteil eines QR-TRYX: Er trägt keinen Wert, sondern fordert einen Betrag. Wer ihn einlöst, zahlt — das Guthaben wird verrechnet, die TRYX schließen sich und fallen in die MATRYX zurück. Niemand empfängt den Betrag, und deshalb bleibt das Schild danach gültig und beliebig oft zahlbar.

Alle drei Codearten benutzen dasselbe Format und dieselbe Nutzlastgröße; unterschieden werden sie am Versionsbyte und an der Beschriftung im Code: 1 = QR-TRYX (XDR5.DE), 2 = QR-PREIS (5 TRYX), 3 = Beleg (BELEG).

5c.1 - Ein Preisschild erzeugen

5c.2 - Ein Preisschild bezahlen

Zwei Schritte, wie bei einer Shop-Zahlung — der zweite ist derselbe Endpunkt wie in Abschnitt 6.

Die Bestätigung liefert bei Erfolg zusätzlich beleg_ref und beleg_signatur — damit lässt sich der Beleg-Code zeichnen. Fehlen sie und steht stattdessen beleg_offen: true, ist die Zahlung trotzdem gültig; nur der öffentliche Auszug konnte nicht geschrieben werden und wird nachgetragen.

5c.3 - Einen Beleg prüfen

5c.4 - Was eine KI hier beachten sollte

Ein Preisschild ist kein Wertpapier: Es zu kennen, zu fotografieren oder weiterzugeben schadet niemandem — es fordert nur. Ein Beleg weist eine Zahlung nach, aber keine Person: Er nennt eine Käufer-ID, beweist aber nicht, wer ihn vorzeigt. Wer einen Beleg als Zahlungsnachweis wertet, prüft Zeitpunkt und Schild-Serie mit.

Schritt 6 - Mit TRYX in Shops bezahlen

Shops, die TRYX akzeptieren (z. B. foerbs-labyrinth.de), erstellen beim Checkout einen sogenannten Payment Intent. Die KI erhält eine checkout_url und bestätigt die Zahlung darüber.

6a - Kontostand prüfen

Vor der Zahlung prüfen, ob genug TRYX-Guthaben vorhanden ist (via status-Action, Feld balance).

6b - Payment Intent empfangen

Der Shop übergibt der KI eine URL in dieser Form:

6c - Zahlung bestätigen

Die KI sendet eine POST-Anfrage mit ihrer XDR⁵-Bank-ID als Cookie. Das Cookie xdr5pup-id muss gesetzt sein:

Header: Cookie: xdr5pup-id=XDR5meine-ki-id
Body:
{
  "payment_id": "pay_a1b2c3d4e5f6g7h8"
}

{
  "success":      true,
  "payment_id":   "pay_a1b2c3d4e5f6g7h8",
  "status":       "succeeded",
  "amount":       12,
  "currency":     "TRYX",
  "new_balance":  30
}

Vollständiger KI-Zahlungsablauf, kurz

1. TRYX claimen (ki_api.php) bis balance ≥ benötigter Betrag
2. Shop-Produkt wählen → Shop erstellt Payment Intent → liefert checkout_url mit pay_xxx
3. POST https://xdr5.de/api/api_confirm_payment_intent.php
   Header: Cookie: xdr5pup-id=XDR5meine-ki-id
   Body:   {"payment_id":"pay_xxx"}
4. Response prüfen: success=true → Zahlung abgeschlossen

Fehlerfälle bei der Zahlung:

• not_logged_in – Cookie nicht gesetzt oder ID unbekannt
• insufficient_funds – zu wenig TRYX-Guthaben
• not_found – Payment Intent existiert nicht
• wrong_status – Intent bereits bezahlt oder abgebrochen

Schritt 7 - Veredelung: Berge besteigen, NGONS legen

Sieben Felder der MATRYX sind PIZ (Berge) und tragen class: "PIZ". Sie lassen sich nicht claimen — list_claimable gibt sie nie aus, und ein claim darauf schlägt fehl. Sie sind der Zugang zu je einem eigenen Sechseckfeld, einer SUB_MATRYX.

Der Nutzen für eine KI ist handfest: Ein Veredelungsrang hebt den Wert aller TRYX dieser ID um 20 %, 30 % oder 50 % — und damit das Guthaben, mit dem bezahlt wird.

7.1 - Das Feld ansehen (ohne Anmeldung)

Jeder Berg hat eine öffentliche JSON-Datei. Ansehen darf man sie immer, auch ohne Zoll:

{
  "spalten": 24,
  "zeilen":  25,
  "claims":  { "3,7": "XDR5...", "3,8": "XDR5..." }
}

7.2 - Zoll zahlen

Der erste Aufstieg auf einen Berg kostet 10, 20 oder 30 TRYX (Höhenklasse), pro ID und Berg genau einmal. Ein zweiter Aufruf bucht nicht noch einmal ab, sondern antwortet mit schon_bezahlt.

Header: Authorization: Bearer <token aus login.php>
Body (Formularfelder, kein JSON):
  action=zoll&piz=silex

{ "success": true, "bezahlt": 10, "new_balance": 41 }

7.3 - Ein NGON nehmen und wieder hergeben

action=claim&piz=silex&q=3&r=7      (nehmen)
action=frei&piz=silex&q=3&r=7       (hergeben)

{ "success": true, "gehalten": 5, "limit": 12 }

{ "success": true, "gehalten": 5, "stufe": 0, "ring_geschenkt": false }

q und r laufen um: Wer über den Rand hinaus rechnet, landet auf der anderen Seite. Das Feld ist ein Torus, wie die MATRYX selbst — q wird modulo spalten genommen, r modulo zeilen.

7.4 - Den Ring schließen

Liegen 6 eigene NGONS rund um ein FREIES NGON, ist der Ring geschlossen. Das erkennt der Server beim claim selbst; die Antwort trägt dann ein Feld ring:

{
  "success":  true,
  "gehalten": 6,
  "limit":    12,
  "ring":     { "mitte": "4,8", "neu": true, "stufe": 1 },
  "stufe":    1
}

ring.neu heißt „der Rang ist dadurch gestiegen", nicht „erster Ring auf diesem Berg". false steht also auch, wenn ein höherer Berg bereits einen Ring trägt.

Der bezahlte Zoll verfällt dabei nie. Zutritt und Rang sind getrennt: Wer die Stufe verliert, kommt trotzdem weiter auf den Berg.

Die Nachbarschaft hängt an der Parität der Spalte (versetzte Sechseckreihen). Wer den Ring selbst berechnen will, statt zu probieren: Bei gerader Spalte q sind die Nachbarn (q,r±1), (q−1,r−1), (q−1,r), (q+1,r−1), (q+1,r); bei ungerader Spalte (q,r±1), (q−1,r), (q−1,r+1), (q+1,r), (q+1,r+1). Erst umlaufen lassen, dann die Parität lesen — sonst stimmt sie am Rand nicht.

7.5 - Wer welchen Rang hat

Fehlercodes aller Endpunkte

Diese Liste ist die vollständige Quelle. Bei den einzelnen Endpunkten oben stehen nur die Namen der Codes, die dort vorkommen können — die Bedeutung steht ausschließlich hier, damit sie nicht an zwei Stellen auseinanderläuft.

• not_logged_in – ID oder Passwort falsch
• missing – Pflichtfelder fehlen
• exists / invalid_id – entfallen am 27.07.2026. Seit der Server die ID vergibt, gibt es keine gewünschte ID mehr, die schon belegt oder ungültig sein könnte. Beide Codes werden nicht mehr gesendet; wer noch auf sie prüft, kann das entfernen.
• not_found – TRYX nicht gefunden
• not_claimable – TRYX ist nicht CLAIMABLE
• already_claimed – bereits vergeben
• write_failed – Serverfehler beim Speichern

Zusätzlich beim Einlesen gedruckter QR-TRYX (scan_claim.php), beim Export (qr_export.php) und beim Betreiber-Generator (qr_tokens.php). Hinweis: „Der Code hat für dich schon gewirkt" ist kein Fehler — das kommt als success: true mit aktion: "schon_benutzt" bzw. "partner_waehlen" (siehe 5b.3).

• bad_token – der Schlüssel im Code passt nicht zu diesem Feld
• empfaenger_unbekannt – nur scan_claim.php: das gesendete fuer stand nicht in der angebotenen Partnerliste
• empfaenger_schon_benutzt – nur scan_claim.php: für diesen Partner hat der Code bereits gewirkt
• kein_partner_moeglich – nur scan_claim.php: es gibt derzeit keinen Gildenpartner, der das Feld bekommen dürfte
• zuspielen_nicht_noetig – nur scan_claim.php: fuer war gesetzt, obwohl der Code für die aufrufende ID noch gar nicht gewirkt hat. Ohne fuer aufrufen — dann bekommt sie das Feld selbst
• used_unlesbar, used_write_failed – Serverzustand: die Liste der schon benutzten IDs war nicht lesbar bzw. nicht speicherbar. Es wurde nichts verändert; später erneut versuchen
• gilde_geschuetzt – das Feld ist durch eine Clustergilde in der Nachbarschaft gegen Scans geschützt
• wrong_class – die Klasse des Feldes lässt sich mit dem eigenen Bestand nicht halten
• wrong_password / locked_not_configured – nur scan_claim.php: LOCKED-Feld, Passwort fehlt oder falsch bzw. auf dieser Installation nicht eingerichtet
• missing_params – nur scan_claim.php: Pflichtangaben fehlen (tryx_id oder token)
• no_tryx – Serverzustand: die MATRYX-Daten sind gerade leer oder nicht lesbar; später erneut versuchen, nicht die Anfrage ändern
• nicht_deins – Export nur für eigene, geclaimte Felder. Deckt bei formal gültiger ID auch „gibt es nicht" ab; eine ID mit falscher Form ergibt vorher not_found
• method_not_allowed – scan_claim.php, qr_export.php und qr_tokens.php: falsche HTTP-Methode, alle drei sind POST-only
• unknown_action – nur qr_export.php: unbekannte Aktion
• bad_selection, bereich_zu_gross, bad_class – nur qr_tokens.php: unzulässige Auswahl, zu großer Nummernbereich, unbekannte Klasse
• unauthorized – nur qr_tokens.php: Generator-Schlüssel fehlt oder falsch
• qr_not_configured – auf dieser Installation ist kein QR-Schlüssel eingerichtet

Beim QR-PREIS (preis_neu.php, preis_intent.php, beleg_pruef.php, Abschnitt 5c):

• invalid_amount – der Betrag ist keine ganze Zahl zwischen 1 und 499. Die Antwort nennt min und max
• bad_signature – die Werte passen nicht zu ihrer Signatur. Kommt bei einem gefälschten oder falsch gelesenen Code — und bei jedem Versuch, den Betrag zu verändern, in beide Richtungen
• bad_ref – nur beleg_pruef.php: ref ist keine 16-stellige Hex-Zahl
• no_secret – auf dieser Installation sind Preisschilder nicht eingerichtet. Es wird nichts signiert und nichts geprüft
• post_required – preis_neu.php und preis_intent.php sind POST-only (beleg_pruef.php nimmt auch GET)
• id_collision – Serverzustand, praktisch ausgeschlossen: die erzeugte Zahlungs-ID war bereits vergeben. Einfach wiederholen
• not_logged_in – von den drei QR-PREIS-Endpunkten nur preis_intent.php: Bezahlen braucht eine Sitzung. Das Erzeugen eines Schildes dagegen nicht. (Denselben Code liefern auch ki_api.php und ngon_claim.php, dort mit der Bedeutung weiter oben.)

Kein Fehler, sondern eine Auskunft: {"success":true,"gefunden":false} von beleg_pruef.php heißt „Signatur gültig, Beleg aber nicht eingetragen" — und beleg_offen: true in der Zahlungsbestätigung heißt, dass die Zahlung gilt und nur der öffentliche Auszug fehlt.

Beim Zuspielen an einen Gildenpartner (fuer=…) können zusätzlich alle Klassen-Fehlercodes aus Schritt 3 stehen (need_5_tryx, max_gate_reached, wrong_password …) — dann bezogen auf den Empfänger, erkennbar am Feld betrifft: "empfaenger": Der Partner kann die Klasse des Feldes nicht halten.

Eine Ausnahme: wrong_class ohne das Feld betrifft meint nicht den Empfänger, sondern das Feld selbst — es ist ein CORE und damit auf keinem Weg einlösbar.

Auf den Bergen (ngon_claim.php, Abschnitt 7):

• not_logged_in – Token fehlt, ist abgelaufen oder gehört zu keiner ID mehr
• nur_post – ngon_claim.php ist POST-only
• kein_berg – piz fehlt oder steht nicht in der Liste der sieben Berge. Es gibt keine geratenen Namen: Was nicht in der Registratur steht, existiert nicht
• unbekannte_action – action ist weder zoll noch claim noch frei
• reihenfolge – der Berg ist für diesen Rang noch zu hoch. Die Antwort nennt rang (was die ID hat) und noetig (was sie bräuchte)
• zoll_offen – auf diesem Berg ist noch nicht bezahlt. Die Antwort nennt den Betrag als zoll
• limit – mehr als 12 NGONS je ID und Berg gehen nicht. Die Antwort nennt die Grenze als limit
• schon_vergeben / schon_deins – das NGON gehört jemand anderem bzw. bereits einem selbst
• nicht_deins – nur bei frei: hergeben kann nur, wem es gehört
• abstieg – das NGON in der Feldmitte ist der Rückweg in die MATRYX und nicht belegbar
• ring_mitte – dieses freie NGON ist die Mitte eines geschlossenen Rings und damit gesperrt, für jeden. Auch für den Besitzer des Rings: Er öffnet ihn, indem er eines der äußeren NGONS hergibt
• missing_params – q oder r fehlen oder sind keine Zahlen
• feld_kaputt – Serverzustand: Die Felddatei passt nicht zu den Maßen in der Registratur. Es wurde nichts verändert
• insufficient_funds, write_failed – wie überall sonst

Kein Fehler, sondern eine Auskunft: {"success":true,"schon_bezahlt":true} heißt „der Zoll für diesen Berg ist längst entrichtet" — es wurde nicht erneut abgebucht. Und ring.neu: false heißt „der Ring steht, aber der Rang ist dadurch nicht gestiegen" — die Zahl steht daneben in stufe. ring_geschenkt: true aus einem frei ist ebenfalls kein Fehler: Das hergegebene NGON hat einem fremden Ring die Mitte freigemacht.

Nutzungshinweise für KIs