Wie der Marktplatz funktioniert

Fünf Zustände. Keine versteckten Übergänge.

1. 1. Pending Lock

   Du hast ein Template gewählt. Der Server baute eine unsignierte Lock-Transaktion. Noch nichts on-chain.

2. 2. Locked

   Dein Wallet hat die Lock-TX signiert und gesendet. Dein ADA liegt jetzt an der Script-Adresse. Der Server hat keinen Zugriff darauf.

3. 3. Instantiiert

   Du hast einen Workspace aus dem Template erzeugt. Er seedet die Dokumente, Diagramme und GTT-Knoten aus dem Manifest.

4. 4. Validiert

   Wenn du GTT-Capabilities auf `active` bringst, verfolgt die Plattform den Fortschritt. Wenn alle erforderlichen Slugs grün sind, kannst du Release auslösen.

5. 5. Released — oder refunded

   Release: du + Plattform co-signieren, Seller:in erhält Auszahlung, Plattform ihre Gebühr. Refund: nach der Deadline signierst du allein und bekommst jedes Lovelace zurück.

Der vollständige Validator-Quellcode liegt im Repo unter `contracts/validators/escrow.ak`. Er ist klein und bewusst lesbar. Kernfakten:

• Zwei Redeemer: `Release` und `Refund`. Nichts anderes spendet das Script.
• Das Datum bindet Buyer, Seller, Plattform, Preis, Template-Hash, Purchase-Id, Deadline und Fee-Bps — alles zum Lock-Zeitpunkt fixiert.
• Gebührenmathematik ausschließlich integer (`price * bps / 10000`). Keine Floating-Point-Rundung, keine Off-Chain-Math, die on-chain nicht prüfbar wäre.
• Das Script ignoriert alles außer `Spend`. Keine Governance-Hooks, keine Migrationen, keine Admin-Keys.

Vollständigen Validator-Code lesen

Beide Bedingungen müssen on-chain erfüllt sein, damit eine Release-TX den Lock-UTxO ausgibt:

• Käufer:in UND Plattform müssen signieren (`extra_signatories` enthält beide Key-Hashes).
• Output-Beträge entsprechen dem Fee-Split: Seller erhält ≥ `price − fee`, Plattform erhält ≥ `fee`.

Die Signierregel der Plattform (off-chain)

Der Validator erlaubt der Plattform das Co-Signing, aber die Plattform selbst prüft vier harte Guards, bevor sie eine Signatur erzeugt. Sie liegen in `src/lib/cardano/escrow/platform-signer.ts` und sind im Repo sichtbar:

1. Kauf-Status ist `locked` — nichts anderes, kein `released` oder `refunded`.
2. `acceptance.acceptanceReachedAt` ist gesetzt — jeder geforderte GTT-Slug hat `active` erreicht.
3. Die TX zahlt an die vom Käufer deklarierte Seller-Wallet und an die Plattform-Wallet — kein Drittempfänger.
4. Der `template_hash` im Datum stimmt mit dem im Kaufdatensatz gespeicherten Manifest-Hash überein — keine Hash-Drift zwischen Lock- und Release-Zeitpunkt.

Vollständigen Validator-Code lesen

Der Refund-Pfad ist einseitig — nur der Käufer signiert. Die Plattform kann ihn weder blockieren noch verzögern noch vermitteln.

• Die TX ist allein vom Käufer signiert.
• Die Untergrenze des Validity-Range liegt auf oder nach `validation_deadline` (on-chain erzwungen).
• Der vollständige gesperrte Betrag geht zurück an die Käufer-Adresse.

Verschwindet diese Plattform morgen, kann jeder gesperrte Kauf nach der Deadline trotzdem vom Käufer zurückgefordert werden. Das ist eine Eigenschaft des Validators, nicht der Plattform.

Templates sind whitelist-gefilterte Exporte eines Workspaces — jede Collection wird gegen ein collection-scharfes Allow-Schema gefiltert, und ein Pattern-Verifier blockt PII-Leaks vor dem Publish. Kein Allow-List-Eintrag, kein Publish.

• Allow-Schemas liegen in `src/lib/server/template-export/schemas.ts` — eines pro Collection, handgeschrieben, keine gemeinsamen Defaults.
• Der Pattern-Verifier scannt jedes erzeugte Manifest auf E-Mails, Wallet-Adressen, Datenbank-IDs, JWTs, UUIDs, Telefonnummern und API-Key-Signaturen.
• User-IDs werden deterministisch in Rollen-Platzhalter (`role:responsible_1`) im Manifest umgemappt. Die Platzhalter-Map selbst wird nie exportiert.
• Creator-Identität ist ausschließlich opt-in. Standard ist vollständig anonym.

Vollständigen Validator-Code lesen