Privacy-First Apps

Beende jede Woche mit einer einzigen Nachricht. Keine Frist, kein Exit-Gespräch, kein Kleingedrucktes. Wir rechnen wöchentlich ab, du bist also maximal die laufende Woche gebunden.

Es steht in deinem Vertrag: Sag es uns, und wir erstatten diese Woche. Keine Rückfragen, keine Rechnungen zum Streiten, keine Eskalationscalls. Einzige Regel: Erstattungen gelten für die letzte Woche.

Weil Stunden die falsche Metrik sind. Wenn wir auf abrechenbare Stunden optimieren, optimieren wir nicht auf dein Ergebnis. Der Deal ist einfacher: Jede Woche müssen wir die nächste verdienen. Wenn wir das nicht tun, zahlst du nicht. Wir können null Stunden oder sechzig investieren. Was zählt, ist, ob du umgehauen bist.

Wir arbeiten mit Operators, nicht mit Lottogewinnern. Wenn eine Anforderung Physik, Gesetz oder Drittanbieter-Systeme brechen würde, sagen wir das, und wenn wir uns nicht ausrichten können, gehen wir. Die Garantie ist gegenseitig: Du kannst uns jede Woche feuern; wir können uns auch selbst feuern.

Wenn die Privacy-Garantie oder die Off-Chain-Compute-Verifikation wirklich tragend für das Produkt ist. Voting-Systeme, Private Identity, skalierbare Rollups und bestimmte Compliance-Flows sind klare Wins. Bei den meisten „pack mal ZK drauf“-Pitches lautet die ehrliche Antwort: „Eine Datenbank mit Auth reicht und ist 100× günstiger.“ Das sagen wir dann auch.

Wir dimensionieren die Proving-Infrastruktur schon in der Architekturphase, nicht erst nach dem Launch. Off-Chain-Proving mit On-Chain-Verifikation (das Standard-Pattern) läuft bei gut entworfenen Circuits typischerweise in Millisekunden bis Sekunden. Wir benchmarken auf echter Hardware, bevor wir uns festlegen – und sagen dir, wenn die Proving-Kosten den Use Case unwirtschaftlich machen.

Oft ja. ZK muss nicht die ganze App sein. Es kann ein Verifier-Contract sein oder ein einzelner Proof-Generation-Flow innerhalb eines klassischen Stacks. Wir haben ZK-Identitätsverifikation, private Balance-Checks und Proof-of-Membership in ansonsten ganz normale Web-Apps integriert. Der harte Teil ist meistens UX, nicht Kryptografie.

Groth16 für kleine, feste Circuits mit minimalen Verification-Gas-Kosten (gut für Ethereum Mainnet). PLONK oder Halo2 für general-purpose Circuits, wenn du ein universelles Trusted Setup willst – oder gar keins. STARKs (Cairo, RISC Zero, Boojum), wenn du Post-Quantum-Sicherheit oder transparentes Setup brauchst. Noir oder Circom fürs Circuit-Authoring, je nach Team-Erfahrung. Wir wählen danach, was auf deiner Zielchain am günstigsten verifiziert und was deine Entwickler auditieren können – nicht danach, was auf Twitter am lautesten ist.

Privacy-Flow-Erweiterung einer bestehenden dApp (ein Circuit + Verifier-Contract): 25.000–50.000 €. Eigenständiges ZK-Identity- oder Membership-Produkt: 50.000–120.000 €. ZK-Rollup oder App-Specific-Chain: 200.000 €+ und 6–12 Monate, mit Audit als nennenswertem Posten. Audit-Kosten für ZK-Circuits liegen höher als für reines Solidity (30.000–80.000 € für nicht-triviale Circuits), weil die Angriffsfläche mathematisch ist, nicht nur Code. Wir quotieren das Audit-Budget gleich neben dem Build-Budget, damit es dich nicht später überrascht.